Post 2 of 4. In Post 1 we established that an EBS customer is not one record but six TCA entities. Now we look at where those entities should live while you are processing them — and why that decision matters more than most teams realise.
Most migration teams make their biggest architectural decision without realising they are making one. It happens early in the project, usually in a practical conversation about where to put the data while it is being processed. And the answer that gets chosen — almost by default — shapes everything that follows.
The decision is: where does your migration data live between EBS and Fusion?
There are broadly two approaches in the field. One is to extract data from EBS into flat files — CSVs or spreadsheets — map those files to Oracle’s FBDI templates, and load them into Fusion. The other is to extract data from EBS into a dedicated database staging environment — specifically Oracle Autonomous Transaction Processing (ATP) or Autonomous Data Warehouse (ADW) — run all your validation and transformation there, and generate the FBDI files programmatically from that staging layer.
These two approaches produce radically different migration experiences. One of them will serve you well on a Tuesday afternoon. The other will serve you at 2am on cutover weekend when something goes wrong.
What the flat file approach cannot do
When your migration data lives in flat files, your migration intelligence lives nowhere. You cannot query ‘how many records are currently in flight in the ESS job?’ You cannot ask ‘which records passed our validation but failed Fusion’s import job?’ You cannot answer ‘is the file we are about to upload the same one we validated an hour ago, or did someone regenerate it?’
These are not edge-case questions. They are the questions that get asked every time something unexpected happens during a migration run. And they will get asked. Every project has unexpected moments. The question is whether you can answer them quickly or whether you are guessing.
What ATP gives you that files cannot
When your staging layer is an ATP database, your migration has a status model. Every record in every staging table carries a status that tells you exactly where it is in the migration lifecycle: EXTRACTED, VALIDATED, IN_FBDI, LOADED, VAL_ERR, FUSION_ERR, CORRECTED, EXCLUDED. At any moment, for any object, you can run a single query and know precisely how many records are in each state.
It also gives you a run control table — a record of every extraction run, every FBDI file generated, every ESS job submitted, every reconciliation completed, and who signed off on each one. When someone asks at 3am on cutover weekend ‘is this the same file we validated two hours ago?’ the answer is a query, not a conversation.
And it gives you validation logic that runs close to the data. Your Tier 1 checks — null fields, invalid country codes, duplicate primary Bill-To flags, missing payment term mappings — run as PL/SQL procedures in ATP, against the actual staging data, with every failure written to a validation log table at the check level. Not ‘record 4821 failed,’ but ‘record 4821 failed because COUNTRY = YU which is not in Fusion’s territory reference data.’
The practical case
We have run migrations both ways. Flat file migrations are faster to start — you can extract data and start mapping columns the same day. But they accumulate technical debt quietly. Every time something goes wrong, the investigation takes longer than it should. Every re-run requires more manual coordination. And the closer you get to cutover, the more that accumulated friction costs you.
ATP staging migrations take more effort to set up — the schema, the status model, the validation procedures, the run control framework. But from the moment that framework exists, every subsequent step is faster, safer, and more auditable. The effort pays back many times over by the time you reach SIT.
In the next post we will look at the five-layer migration stack that sits on top of this staging foundation — and specifically why an integration platform like OIC has no role in a migration.
