The hard part of a JD Edwards EnterpriseOne Table Conversion project for legacy data migration is almost never the mapping. Field-to-field mapping is mechanical work that can be specified in a spreadsheet by a functional analyst in two weeks. What kills these projects is the load order across F0101Address Book Master table — the master file every transactional table in JDE refers to through the AN8 column., F4101, F0911 and the transactional siblings, and the absence of a reconciliation pack the business is willing to sign.

I have led six legacy-to-JDE migrations in the last five years, with row counts ranging from 800,000 up to roughly 40 million across all loaded tables. The pattern that distinguishes the cutovers that closed on time from the ones that bled support tickets for nine months is consistent — and it has nothing to do with how clever the transformation logic was.

What a Table Conversion really means in JDE

In JDE terminology the Table Conversion is a specific object type (TC) generated through OMWObject Management Workbench — the JDE tool used to check out, modify and promote any custom object including Table Conversions, BSFNs, UBEs and applications. and executed through R98403-style logic. The wider engineering effort that moves data from an outgoing system into JDE production tables almost always combines three execution tools: the generated TC object, custom UBEs built in RDA, and Orchestrator flows for the lighter loads.

A pure TC object is the cheapest tool to build and the hardest to extend. It works well when the source row maps cleanly to one target row with light transformation — payment terms, item categories, address book extensions. The moment the load needs multi-table writes (a sales order touches F4201 and F4211, with potential F4209 prices and F4106 base prices), NextNumbers acquisition, or per-row validation against UDC tables, the TC object stops being the right choice. A custom UBE built in RDA, with proper Event Rules and BSFN calls, is the only honest answer.

The misunderstanding I see most often, from clients and from junior consultants, is treating "Table Conversion" as a synonym for the full migration. It is one tool inside the toolbox, not the toolbox itself. Get this wrong at the start of the project and the entire estimate is off by a factor of two.

The five-stage backbone that does not change

Every successful migration into JDE E1 follows the same five-stage backbone: extract, stage, convert, load, verify. Tooling changes between projects. The stages do not.

Extract pulls data out of the outgoing system into a neutral format — SQL exports, CSV, or flat files written to a staging share. The rule I never break: do not connect any JDE process directly to a live legacy database. Take a frozen, auditable snapshot you can replay any number of times. Replays are not optional; they will happen, usually at 2 AM on a Saturday.

Stage lands the extracted rows into custom F55* tables on the JDE side, patterned after the standard F5511Z1 interface table convention: every source column, plus EDUS, EDBT, EDTN, EDLN, EDSP control columns and a processing-status flag. Staging is where validation queries run repeatedly without touching production. Convert transforms each staged row against the JDE rules: UDCUser Defined Codes — the JDE lookup tables stored in F0005 and F0004 that validate codes used by virtually every transactional table. validation against F0005, date normalisation to Julian, NextNumbers from F0002 when the target column is a document number. Load writes only validated rows into JDE production. Verify closes the loop with counts, key-integrity checks, and financial totals.

The single phase most projects underfund is verify. Three to five days of reconciliation work, planned at the start, prevents three to six months of post-go-live support noise.

The load order that determines whether the project ends cleanly

Load order is the technical decision with the highest blast radius in the whole project, and it is almost always made too late. The rule, stated bluntly: masters before transactions, always, with no exceptions for "convenience" or "we will fix the orphans later". F0101 (Address Book Master) and F0111 (Who's Who) before any transactional table that references AN8. F4101 (Item Master) and F4102 (Item Branch) before sales orders, purchase orders or inventory transactions. F0901 (Account Master) before any F0911 journal line. F4801 (Work Order Master) before F4801T or F31* manufacturing details.

What "orphans" really means in practice: a customer ledger row in F03B11 with a customer number that does not exist in F0101 will not raise an error at load time, because JDE physical files have no enforced foreign keys at the database level. The row sits there. Three weeks after go-live, the Aged Receivables report shows a balance that does not tie to anything on the customer master, and someone has to write a CTE to find the orphans, match them against legacy backups, and decide whether to create or delete.

The cost of getting load order right is one extra week of dependency-graph work during design. The cost of getting it wrong is open-ended.

Idempotency, restartability and the cutover window

The single property every load UBE in the project must have is idempotency: running the same UBE twice with the same input produces the same final state. The simplest pattern is "delete-where-source-batch-id then insert", scoped to a batch number the load itself owns and writes into a control column. Without idempotency, every failure during cutover forces a restore-from-backup, which on a 40-million-row dataset means the cutover window doubles.

Restartability is the related property: a UBE that aborts at row 4 million must be able to resume from row 4 million plus one, not from row one. Checkpoint logic in the staging table — a "last_committed_row" column updated every 10,000 rows — is twenty lines of EREvent Rules — the visual scripting language used inside JDE UBEs, applications and BSFNs to encode business logic without writing C code. code and saves entire cutover weekends. I have run cutovers where the load failed three times for unrelated infrastructure reasons (network blip, expired DB token, full transaction log) and still landed on plan because the restart logic was already in place.

The cutover window itself is the period during which legacy writes are blocked and the final delta load runs. The smaller the window, the more delta loads ran beforehand. Two weekends of delta rehearsal before the real one is the minimum; four is normal. Each rehearsal exposes a different failure mode — the third rehearsal usually finds the UDC value that was added to the legacy system three months after the spec was frozen.

Reconciliation as the deliverable that closes the project

A migration ends when the business signs the reconciliation pack, not when the last UBE returns RC=0. The pack I deliver on every project has three components: row counts per source-target pair, financial totals (sum of AG in F0911 matched against the legacy trial balance to the cent), and an exception list of rows that did not load with a typed reason for each one.

Row counts are the easy part — a two-column SQL query against the staging table and the production table per pair. Financial reconciliation is the part that fails most often, because the two systems compute period balances differently and the natural assumption that "if the journal lines match, the balances match" is wrong. F0902 period balances must be recalculated from the loaded F0911 lines using UBEUniversal Batch Engine — JDE's batch report runner, used here for the standard F0902 period balance recalculation job after journal lines are loaded. R09866 or equivalent, otherwise the trial balance will be off by the sum of every journal line that crossed a period boundary.

The exception list is where engineering credibility lives. Forty thousand sales orders loaded, two hundred and eighty rejected with reason codes — that is a defensible result. Forty thousand loaded, "some rejected" — that is a project that has not closed. Once the business signs that pack against named individuals on the finance side, the migration is genuinely complete. Anything that surfaces later is post-implementation support work, not migration debt. The discipline of the reconciliation pack is what turns one into the other.

If the depth of detail above is the kind of perspective you want on JDE work, the related articles on retrofitting copies of standard, on UBE checkpoint patterns, and on F0911 reconciliation after go-live go deeper into each piece touched on here. The technical project portfolio on this site also documents two of the migrations that produced these conclusions, with anonymised numbers.