Many Oracle E-Business Suite (EBS) customers are now planning their move to Oracle Fusion Cloud ERP. The first thing to accept is that this is not a technical upgrade. EBS is software you run and modify. Fusion is a SaaS service that Oracle updates every quarter and that you configure rather than customise.
That changes how you plan. You cannot copy EBS code, tables or forms into Fusion. You redesign processes, decide which data really needs to move, and rebuild only what the business still needs. This checklist walks through the ten areas we see decide whether an EBS to Fusion migration goes well.
Reimplementation vs lift: get the language right
"Lift and shift" is a real option for EBS, but it means moving EBS itself onto Oracle Cloud Infrastructure (OCI). It keeps your customisations and your upgrade cycle. Moving to Fusion Cloud ERP is a reimplementation: new setup, new data loads, new integrations and new reports. Some organisations do both, running EBS on OCI while finance moves to Fusion in phases. Be clear with your board and auditors about which one you are doing.
The 10-step EBS to Fusion migration checklist
1. Assess customisations (RICEW / CEMLI)
List every report, interface, conversion, extension and workflow (RICEW), or configuration, extension, modification, localisation and integration (CEMLI) if that is your inventory format. For each item, record the owner, how often it is used and the business reason. Then sort them into four groups: retire, meet with standard Fusion, rebuild as an extension or integration, or rebuild as a report. Oracle describes Fusion as configurable rather than customisable, so plan for personalisation and extensions, not code changes to the application.
2. Decide the scope and phasing
Choose a big-bang move or a phased one by ledger, legal entity, region or module. Finance-first is common because General Ledger, Payables, Receivables and Fixed Assets sit at the centre. Write the scope down and freeze it before design starts.
3. Redesign the chart of accounts
Do not copy the EBS chart of accounts by default. Years of new segment values, unused accounts and reporting workarounds build up. Use the move to simplify segments, align with management and statutory reporting, and set up cross-validation rules properly. Build a mapping from every old account combination to the new structure. This mapping drives balance conversion, reconciliation and historical reporting.
4. Agree the data scope: open balances vs history
Decide object by object what moves. A typical finance scope looks like this:
| Data area | Usually migrate | Usually archive in EBS |
|---|---|---|
| Suppliers and customers | Active records only | Inactive and duplicate records |
| Payables and Receivables | Open invoices and unapplied receipts | Paid and closed transactions |
| General Ledger | Opening balances, plus 1-2 years of period balances if needed for comparisons | Journal-level detail from earlier years |
| Fixed Assets | Active assets with cost and accumulated depreciation | Retired assets and full depreciation history |
| Purchase orders | Open POs | Closed and cancelled POs |
Fusion loads most of this through File-Based Data Import (FBDI) templates. Oracle's flow is to prepare the file from the template, load it into interface tables, run the import process for that object and correct errors. Oracle's guide to importing file-based data into Fusion Cloud ERP also shows how Oracle Integration can automate these loads.
5. Rebuild integrations on Oracle Integration (OIC)
List every EBS interface: banks, payroll, tax, procurement portals, data warehouses and in-house systems. Many EBS interfaces write directly to open interface tables or call PL/SQL. Fusion does not allow that. Plan each one on Oracle Integration using the Oracle ERP Cloud Adapter, REST services or FBDI-based bulk loads. See the Oracle Integration documentation and our OIC to ERP Cloud playbook.
6. Move reports to OTBI and Analytics Publisher
Many EBS custom reports exist only because the standard ones were hard to use. Check the predefined Fusion reports first. Rebuild ad hoc and operational reports in Oracle Transactional Business Intelligence (OTBI) and formatted outputs such as statutory layouts or remittance advice in Oracle Analytics Publisher (formerly BI Publisher). Decide early where users will look up EBS-era history.
7. Map security roles
EBS responsibilities do not map one-to-one to Fusion roles. Fusion uses role-based security managed in the Security Console, and Oracle notes that data roles are no longer used in ERP Cloud. Start from the predefined job roles, copy and adjust where needed, and design data access by ledger and business unit. Review segregation of duties before user acceptance testing, not after.
8. Plan testing cycles
Run at least two or three mock data loads, each followed by reconciliation of counts and balances back to EBS. Then run system integration testing with real interfaces, user acceptance testing with business users and a parallel close if your auditors expect one. Our FBDI validation guide covers the reconciliation checks.
9. Rehearse and run cutover
Write an hour-by-hour cutover plan: EBS period close, transaction freeze, final extracts, loads, reconciliation sign-off, integration switch-over and go/no-go. Rehearse it at least once with production-sized data. Use our go-live readiness and cutover checklist as a starting point.
10. Archive EBS and decide on coexistence
After go-live, keep EBS read-only for a defined period, or extract its history into a reporting store, so auditors and tax teams can reach old transactions. Agree retention periods with finance and legal. If you are moving in phases, plan coexistence: EBS and Fusion running side by side, connected through Oracle Integration with the E-Business Suite Adapter and the ERP Cloud Adapter. Oracle publishes a reference architecture for this. Typical coexistence flows are GL journals from EBS into Fusion, or shared supplier data.
Pre-migration checklist
- RICEW / CEMLI inventory complete, with owner and decision for each item
- Scope and phasing approved by finance and IT leadership
- New chart of accounts designed, with full old-to-new mapping
- Data scope agreed per object: migrate, archive or purge
- Data cleansing started in EBS (duplicates, inactive suppliers, unreconciled items)
- Integration list mapped to OIC patterns
- Report list triaged: standard, OTBI, Analytics Publisher or retire
- EBS responsibilities mapped to Fusion job roles
- Mock load and reconciliation dates fixed
- Cutover plan drafted and rehearsal booked
- EBS archive and access approach agreed with audit
- Coexistence design signed off, if phased
Common mistakes
Treating it as an upgrade. Teams that copy EBS designs into Fusion end up with workarounds and extensions they do not need.
Moving all history. Loading years of closed transactions slows every mock load and adds little value. Archive instead.
Keeping the old chart of accounts by default. This is the best chance in a decade to fix it. Missing it locks problems in.
Leaving integrations late. Banks and third parties need lead time for testing. Start the integration list in week one.
Rebuilding every report. Check standard Fusion reports and OTBI before you build anything.
Mapping security at the end. Late role design delays UAT and creates segregation of duties issues at go-live.
No plan for EBS after go-live. Auditors will ask for old data. Decide where it lives before you switch EBS off.
How Egisedge helps
Egisedge Technologies is an Oracle Partner, founded in 2019, that implements Oracle Fusion Cloud ERP, HCM and SCM, Oracle Integration Cloud and OCI. Our directors bring 20+ and 16+ years of hands-on Oracle EBS and Fusion experience in finance and supply chain. We help EBS customers triage customisations, redesign the chart of accounts, plan FBDI data migration and rebuild integrations on OIC. Our teams work from India across GCC, UK/Europe, US and Australia/NZ working hours.
Useful starting points are our FBDI data migration validation playbook and our Fusion Financials setup sequence playbook. For the wider implementation path, see Oracle Fusion Financials implementation steps.
Want help planning your move from EBS to Fusion Cloud ERP? Email info@egisedge.com or book a demo with our team.
Frequently asked questions
Can we lift our Oracle EBS customisations into Fusion Cloud ERP?
No. Fusion Cloud ERP is a SaaS application that you configure and extend, not modify. Each EBS customisation needs a decision: drop it, meet it with standard Fusion features, or rebuild it as an extension, integration or report.
Should we migrate all EBS history into Fusion?
Usually not. Most finance teams load open balances, open transactions and a limited period of GL balances, and keep older detail in a read-only EBS archive or reporting store for audit and look-ups.
Can EBS and Fusion run side by side?
Yes. Oracle supports running EBS and Fusion together, connected through Oracle Integration, so you can move one business unit, entity or process at a time while the rest stays on EBS.
How many test cycles does an EBS to Fusion migration need?
Plan at least two or three data migration mock loads, a full system integration test and user acceptance testing, then a dress rehearsal of the cutover using production-sized data.
Talk to Egisedge about ERP Financials
Tell us where you are and we'll reply within one working day with next steps.