EBS TO ORACLE FUSION CLOUD — CUSTOMER MIGRATION SERIES
When you say ‘migrate our customers’ — this is what you actually mean
⏰ 4 minute read
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.
| 1 | Party (Organisation or Person) | The legal entity at the root of everything. The company or individual you do business with. |
| 2 | Customer Account | The trading account. One party can have multiple accounts. This is what most people call ‘the customer number’. |
| 3 | Address | The physical locations associated with the party. One party can have many addresses. |
| 4 | Account Site | Which of the party’s addresses are used for a specific account. The join between account and address. |
| 5 | Site Use | What each site is used for — Bill-To, Ship-To, Statements. One account site can have multiple uses. |
| 6 | Customer Profile | Credit limits, payment terms, and dunning rules. Exists at account level and at site level. |
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.
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.
“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.
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.
If you found this useful, follow BizInsight Consulting to catch Post 2 when it publishes next week.
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.
www.bizinsightinc.com • Shriram Gupta • BizInsight Consulting
