Post 3 of 4. Posts 1 and 2 covered the TCA data model and why an ATP staging database is the right foundation. Now we look at the five layers that sit on top of that foundation — and the one architectural decision that surprises most teams.
Early in most EBS to Fusion migration projects, someone suggests using the integration platform to orchestrate the migration. It is a reasonable instinct — the integration platform is already there, the team knows it, and it handles complex data flows. But using an integration platform for a data migration is the wrong tool for the job, and understanding why matters.
Migration is not integration. Integration is continuous, event-driven, automated, and designed to run without human intervention. Migration is finite, sequenced, human-supervised, and designed to be controlled at every step. These are different problems that require different approaches.
The five layers that actually belong in a migration
A well-architected customer migration has five layers. Each one has a single job, a clear owner, and a formal exit criterion before the next layer begins. There is no orchestration platform sitting between them — just SQL, scripting, and human judgement.
The discipline that makes this work
The five-layer approach only works with discipline. Layer 2 must run before Layer 3. Layer 5 must complete and sign off before the next object’s Layer 1 begins. If you compress or skip layers — generating FBDI before validation is complete, proceeding to the next object before reconciliation is signed off — you carry problems forward where they are harder to find and more expensive to fix.
The discipline also means documenting everything as you go. Every FBDI file name. Every ESS Job ID. Every reconciliation result. Every sign-off. By the time you reach cutover, the run control table in your ATP staging environment should tell the complete story of every migration run you have ever executed — who ran it, what it produced, what loaded, what failed, and who approved the result.
In the next and final post in this series, we look at how the migration is structured across four waves — and why the trial run two weeks before go-live is the single most important event in the entire programme.
