When you say migrate our customers — this is what you actually mean

 About this series  —  EBS to Oracle Fusion Cloud: Customer Migration

This is Post 1 of 4. Over four posts we cover the complete customer migration journey from Oracle EBS to Fusion Cloud — written for project sponsors, technical architects, and migration teams who want to understand not just what to do, but why the decisions matter.

Post 1: Scope and the TCA data model    

Post 2: Why your staging layer is your most important architectural decision

Post 3: Five layers, no middleware, no exceptions

Post 4: Four waves, one trial run, one chance to get it right

Every migration conversation starts the same way. A client says: “we need to migrate our customer data to Fusion Cloud — how long will it take?” And the answer that comes back is usually a number pulled from the air, because the person answering has not yet looked at what ‘customer data’ actually means inside Oracle EBS.

Here is the reality. In Oracle EBS, a customer is not a record. It is six interrelated entities, each dependent on the previous one, each requiring its own extraction, validation, and load process in a defined sequence. Understanding this upfront is the single most important thing a project team can do before a migration begins.

A client with 50,000 customers may have 300,000+ records to migrate across six entity types. Scoping must account for this.

One architecture. Two systems. The same model.

Here is something that surprises many people encountering this for the first time. Oracle EBS and Oracle Fusion Cloud share the same underlying customer data architecture. It is called the Trading Community Architecture — TCA — and Oracle introduced it to represent the full complexity of modern commercial relationships: a single organisation that is simultaneously a customer, a supplier, and a partner, without duplicating the core party record.

Both systems use TCA. The core table names — HZ_PARTIES, HZ_CUST_ACCOUNTS, HZ_PARTY_SITES, HZ_CUST_ACCT_SITES_ALL, HZ_CUST_SITE_USES_ALL — are the same in EBS and Fusion. The conceptual model is the same. This is not a coincidence. Oracle designed Fusion to receive customer data from EBS implementations, and the shared TCA foundation is precisely what makes that migration tractable.

The practical difference is in how data enters each system. In EBS you worked directly with the database. In Oracle Fusion Cloud — a managed SaaS environment — there is no direct database access. Data enters through Oracle’s File Based Data Import mechanism, via structured CSV templates that map directly to TCA interface tables. The model is the same. The import path is different. That distinction shapes the entire migration approach — and that is what the rest of this series is about.

The six TCA entities inside every customer

Because both systems share TCA, the six customer entities you are migrating are the same six entities in EBS and Fusion. They carry the same structure and the same dependency rules in both systems. Understanding them is the foundation of everything else in this series

 Every one of these six entities must load in order. Accounts cannot load before Parties. Sites cannot load before Accounts and Addresses. Profiles cannot load before Accounts. These are not preferences — Oracle Fusion enforces them at import time. Load in the wrong sequence and you get 100% rejection.

The number that always surprises clients

When teams scope a migration by asking ‘how many customers do you have,’ they typically hear a number like 50,000. What they should be asking is: how many total records across all six entity types? The answer is almost always five to eight times higher.

The number people quote is the number of accounts. The number that matters is total records across all six entities.

Why this matters before you plan

The reason this distinction matters is not just for effort estimation — it changes the entire technical approach. A migration of 50,000 records is a different architecture from a migration of 650,000 records. Batch sizes differ. Validation complexity differs. Cutover window planning differs. Error investigation time differs.

Getting the scope right at the start is what prevents the most common failure mode in migration projects: discovering the real volume two weeks before go-live, when there is no time to adjust the approach.

Up next in this series

Post 2 tackles what is arguably the most consequential architectural decision in the entire migration: where does your data live between EBS and Fusion? We compare two approaches — flat files versus an ATP staging database — and make the case for why the staging layer is the place where migration projects are won or lost, long before any data reaches Oracle Fusion.

Let's talk.  If you are planning an EBS to Fusion Cloud migration and want to talk through scope, approach, or where we have seen projects go wrong — we would be glad to have that conversation.

If you found this useful, follow BizInsight Consulting to catch Post 2 when it publishes next week.

50,000 customer accounts might mean 50,000 parties, 50,000 accounts, 120,000 party sites and addresses, 120,000 account sites, 280,000 site uses, and 50,000 customer profiles. That is over 650,000 records — not 50,000. And every one of those records needs to be extracted, validated, loaded, and reconciled before a single invoice can be raised in Fusion.