Complete Guide to Migrating Data from Oracle eBusiness Suite to Oracle Fusion Cloud ERP

Oracle E-Business Suite (EBS) is Oracle’s long-established, on-premise ERP (Enterprise Resource Planning) system that integrates finance, supply chain, HR, and other business functions. It has been around for decades, runs primarily on customer-managed infrastructure, and requires significant customization and maintenance.

Oracle Fusion Applications (Oracle Cloud ERP) are Oracle’s modern cloud-based ERP solutions, built on newer technologies with AI, machine learning, and analytics embedded. They are delivered as Software-as-a-Service (SaaS), updated regularly by Oracle, and designed for scalability, flexibility, and lower infrastructure costs compared to EBS. 

In the coming decade, many organizations are expected to partially or fully transition from Oracle E-Business Suite (EBS) to Oracle Fusion Applications as part of their modernization journey. One of the most critical aspects of this transition is data migration, which, if not carefully planned, can become a significant risk to project success.  

Key Challenges of Migrating Data from Oracle eBusiness Suite to Oracle Fusion

The key challenges of migrating data from Oracle eBusiness Suite to Oracle Fusion are the following:  

• Differences in Data Models: While some data structures in EBS and Fusion are similar, there are also significant differences. Project teams must invest time in carefully mapping data to ensure seamless integration into the new system. 
• Customizations: Over the years, EBS environments often accumulate customizations and custom data. During migration, organizations need to decide whether to handle these through standard functionality available in Fusion or by developing extensions. 
• Uptime and Downtime Management: Minimizing system downtime is crucial. A long blackout period where users cannot enter data in either system can disrupt operations and result in financial loss. Careful planning is needed to reduce this risk. 
• Data Integrity: Accuracy and consistency of data must be maintained throughout the migration process. Any compromise here can lead to serious reporting errors, compliance issues, and operational inefficiencies. 

How is the Process of Migrating Data From Oracle eBusiness Suite to Oracle Fusion Different? 

In EBS, inbound data migration typically uses PL/SQL procedures that invoke APIs or interface tables with concurrent programs loading into Oracle. For Fusion migration, however, note that: 

No direct SQL access to the Fusion Oracle database; therefore, no table inserts or PL/SQL within the Fusion database. You can perform SELECT statements, but it is not straightforward. You can go through our blog for more information. 

Data should be loaded into staging tables via FBDI (File-Based Data Import) or HDL (HCM Data Loader) templates. Direct API calls are disallowed; although web services are available, they are not feasible for large data sets. 

This manual provides details for moving from Oracle E-Business Suite to Oracle Fusion and addresses common Oracle Fusion migration considerations.

If you are an Oracle E-Business Suite technical developer or project manager, this is your jumping-off point. A data migration strategy from any source is presented in our blog. 

Also Read: Oracle Fusion Joins Explained: Types, Examples, and Best Practices

Understanding the Difference Between EBS and Fusion Data Models 

The data models in Fusion and EBS are not the same. But if you are migrating data from Oracle eBusiness Suite to Oracle Fusion, you are better off than the rest. Most tables in many of the modules are very similar. For instance, in the HCM module, PER_ALL_PEOPLE_F stores employee details in both EBS and Fusion, but the structures differ.

Likewise, you will find many tables, including PO_HEADERS and FND_LOOKUP_VALUES, in Oracle Fusion. But there are differences that you must know about: 

• FND_USER and FND_RESPONSIBILITIES are nowhere to be found in Fusion. Instead, check tables such as PER_USERS, PER_ROLES, etc., for related information. 
• Descriptive Flexfields and Key Flexfields remain; you will have ATTRIBUTE columns in nearly every table. Fusion brings Extensible Flexfields, so data loading into these will have to be taken into account. 

Your safest bet is to work through the tables and familiarize yourself with the mappings. 

For in-depth details of Fusion table structures, please see the material below: 

• Fusion HCM Table Structure 
• Fusion SCM Table Structure 
• Fusion Financials Table Structure 

Reporting Differences

Reporting is key to data migration, particularly for post-load reconciliation. 

• Oracle eBusiness Suite relies on tools such as Oracle Reports Builder and  Discoverer for custom reports. 
• Fusion uses tools such as OTBI (Oracle Transactional Business Intelligence), BI Publisher, and Smart View. 

Non-migratable Customizations 

There are differences in how customizations are allowed in Oracle Fusion. In the eBusiness suite, you could create your own custom tables to store custom data.  However, Oracle Fusion does not allow that much customization to be that straightforward. 

• Custom forms, report layouts, and workflows of EBS cannot be migrated directly into Fusion. 
• For extensions, keep in mind that any custom table in EBS cannot be replicated in Oracle Fusion. Data can be accommodated in: 

1. Standard data objects, if Fusion has native support for your functionality 
2. Descriptive or Extensible Flexfields. 
3. Custom Objects  
4. Standalone Oracle database servers with custom applications built on top using Oracle APEX or some other technology, well integrated with Oracle Fusion through web service calls. 

The migration team needs to understand the overall plan for migration of custom objects in the data migration strategy document itself.  

You Should Read: Oracle Fusion Data Model & Table Structure Overview 

Planning & Strategy Phase of Migrating Data From Oracle eBusiness Suite to Oracle Fusion

The Planning & Strategy Phase provides the groundwork for an effective migration from EBS to Fusion. It consists of understanding business needs, evaluating the existing EBS environment, determining what data to migrate, and preparing for possible risks and downtime.

Good planning helps ensure that the migration process is well-ordered, reduces errors, and is in line with business priorities. 

Step 1: Conduct Requirement Gathering Workshops 

Migration starts with identifying unambiguously what the business requires. This entails knowing which modules (e.g., Finance, HR, or Supply Chain) are included and what history needs to be brought across. A seasoned Oracle Fusion data migration architect or team lead will conduct requirement-gathering workshops with the business teams.

These workshops assist in aligning expectations, capturing requirements, and making sure that nothing is overlooked before the start of migration work. 

Step 2: Assess EBS Environment 

Inspect the existing EBS environment in depth. This involves verifying the presence of custom data objects and assessing the data quality level (whether the data has been pre-cleaned or contains duplicates).

It is essential to understand the EBS environment to spot potential issues early and ensure the migration method fits the organization’s setup. 

Step 3: Decide the Scope of Migration 

Not all EBS data must be migrated to Fusion. A definitive choice must be made regarding which data objects are within scope, e.g., master data (customers, suppliers, products), transactional data (open invoices, orders), and historic data (closed transactions or archives).  

The scope should generally include a list of data objects to be loaded into Oracle Fusion Applications, the data source, high-level extraction criteria, and the approximate number of records for migration. 

Pro Tip: One of the most debated topics in defining scope is the migration of historical data. Business users often prefer to migrate all historical records for comfort and continuity. However, this poses significant challenges for the data migration team. It’s not just about moving more records; the complexity lies in handling historical references.

For example, a closed invoice may be tied to a customer that no longer exists, requiring additional logic and routines to migrate correctly. Migrating historical data can increase the effort needed for each object by 50% to 100%, impacting timelines, complexity, and even the cutover plan. 

Step 4: Prepare Archival Strategy 

A good practice is to restrict data migration to only active and pertinent records, with the rest of the older data being archived. Archiving ensures that older information is maintained for reporting statutory or audit purposes without adding unnecessary complexity to Fusion.

Migrating obsolete paid invoices and inactive customer accounts, for instance, contributes zero business value and could lead to referential integrity problems. An archival policy keeps the Fusion environment clean, efficient, and less complex to maintain.  

A decision needs to be made on whether to develop a custom archival solution or procure an out-of-the-box solution for Oracle eBusiness Suite. Most System integrators provide such solutions at a cost.

The general idea is to keep all information in database tables in a denormalized form and deploy the necessary reports on top.   

Pro Tip: Avoid asking for the development of extensive “just in case” reports. Start with only the essential reports, and equip the IT team with the skills to build additional reports as needed. This approach minimizes wasted effort on developing and maintaining unused reports while ensuring flexibility for future needs. 

Step 5: Prepare Data Cleansing Strategy 

 This comes from analyzing source data in Oracle E-Business Suite. There are two main types of data cleansing needed before moving to Oracle Fusion: 

1. Mandatory Cleansing (Required by Fusion): Oracle Fusion often has stricter validation rules than EBS. For example, in EBS, addresses may be entered as free text, but in Fusion, postal codes may need to follow a valid format. These cleanups are mandatory. 
2. Business-Driven Cleansing (Good to Have): EBS may have duplicate customers or suppliers due to old errors. It’s a good idea to merge or clean them up during migration. However, this should be balanced so it doesn’t overload the data migration project. 

Different Ways to Do Cleansing

At the Source (in EBS): Data is cleaned directly in EBS before migration. This can run as a parallel project. Either the business team or specialists can correct the production data. This method is best when manual intervention is required. However, some data cannot be changed in EBS because it is still needed for daily operations. 

On the Go (after extraction): Data is cleaned after being extracted from EBS, typically in flat files. This can be done programmatically (e.g., making all customer names uppercase) or manually (e.g., fixing addresses). Manual cleanup here is not recommended because it would need to be repeated for every migration cycle, time is limited between extraction and loading, and the risk of errors is high. 

The strategy document should clearly state he cleansing items and the approach. 

Step 6: Assess the Risk and Plan Mitigation 

Migration poses risks of downtime, data loss, or non-compliance with regulatory requirements. Companies need to schedule a “blackout period” (or cut-over window) during which no new data entry will be allowed in EBS while the migration process is carried out.

The downtime needs to be identified and agreed upon with the company. For instance, some companies can have a one-week blackout, whereas others need migration to be done over a single weekend. Proper planning of this downtime provides little interruption to business processes. 

Step 7: Define Data Migration Team Structure 

A successful data migration project depends on having the right team. The team should bring together technical expertise, business knowledge, and project oversight. Below is a breakdown of key roles and responsibilities: 

Role	Responsibilities
Data Migration (DM) Developers	The role manages the overall data migration workstream, coordinates between teams, tracks progress, and ensures deadlines are met.
Business Representatives	Clarify business requirements, validate migrated data, and provide sign-offs. Their part-time involvement is critical for accuracy and decision-making.
Functional Consultants	Provide clarity on functional configurations and timelines. Support testing and validation of data against Fusion setup. Part-time involvement is usually sufficient.
Technical DM Lead	Oversees technical development, ensures best practices, and supports the developer team.
Data Migration Manager	The role manages the data migration workstream, coordinates between teams, tracks progress, and ensures deadlines are met.

Step 8: Plan Data Migration Cycles & Environments  

Data migration is never a one-time activity; it is carried out in multiple cycles. Typically, at least five full ETL (Extract, Transform, Load) cycles are planned. In each cycle, data is extracted from E-Business Suite (EBS), transformed to meet Fusion requirements, and then loaded into Oracle Fusion.

These cycles allow teams to test, identify errors, and fine-tune the process. By the time of go-live, the team has already rehearsed several times, which significantly reduces the risk of failure. 

Successful migration also depends on the right environments. At the start, a clone of EBS should be created for data extraction instead of using the production environment. Extracting from production may cause synchronization issues (e.g., a new supplier missing from the supplier extract while an invoice for them appears in the invoice extract). 

On the Fusion side, environment setup is now much faster. For a fresh implementation, a new environment is created; for a rollout, a clone of the production instance is used.

This clone is handed over to the functional team for configuration. If manual setup is required, this configuration process may take a few days.  The cycle planning should align with the overall project plan.

Must Read: Oracle Fusion Reporting Challenges Explained 

Data Mapping & Schema Alignment 

After the scope is settled, the second step is to map data from Oracle E-Business Suite (EBS) to Oracle Fusion. As the data models and table structures are different between EBS and Fusion, this step ensures that each field in EBS has a definite place in Fusion. Correct mapping avoids data mismatches, maintains consistency, and minimizes errors during migration. 

Develop a Comprehensive Mapping of EBS Tables & Fields → Fusion Equivalents 

The basis for this step is developing a mapping document that details each source column and table in EBS and its equivalent table and field in Fusion. For instance, customer information kept in HZ_PARTIES in EBS might map to an equivalent table in Fusion, but the structure and naming can be different.

Using resources such as the “Table Mapping between EBS R12 and Fusion” discussions on Oracle Hub is immensely useful. This paper serves as the “blueprint” for the migration team. 

Control Custom Fields and Descriptive Flexfields 

One of the biggest pains is the management of customizations. In EBS, organizations tend to use custom tables or fields. In Fusion, you cannot make custom database tables. You have to use supported extension options such as Descriptive Flexfields (DFFs), Key Flexfields (KFFs), or Extensible Flexfields (EFFs).

For instance, if EBS contains a custom field to hold “Customer Region Code,” this could perhaps be mapped into a DFF in Fusion. Any information held in custom EBS tables must be thoroughly assessed, either migrated into a typical Fusion object, relocated into Flexfields, or dealt with via custom objects and integrations.  

Migration Tools & Methods 

Since Fusion does not allow direct database inserts, migration requires staging areas, templates, and integration tools. Choosing the right approach and tools is key to success. 

Fusion Migration Methods: Oracle provides specialized templates such as FBDI (File-Based Data Import) and HDL (HCM Data Loader). These are the official, supported methods for loading large volumes of data into Fusion.

Any migration tool used should ultimately prepare and deliver data in the Oracle-provided file formats required by FBDI or HDL. 

Method	Approach	Advantages / Disadvantages
Excel Sheets	Extract data as CSV files, open in Excel, and manually convert into Oracle-accepted formats.	✅ Simple and avoids extra migration layers   ✅ Works for small projects   ❌ Impractical for large projects   ❌ High risk of manual errors   ❌ Manual steps repeated in every migration cycle
E-Business Suite Staging Area	Extract data into custom schema tables in EBS, then run PL/SQL procedures to generate Oracle Fusion-ready files.	✅ Eliminates manual processing   ✅ Controlled within EBS environment   ❌ Requires significant PL/SQL development   ❌ Security restrictions may block direct connection from on-premise EBS to Fusion Cloud
Oracle Autonomous Database Staging Area	Set up a staging database in Oracle Cloud Free Tier to store and process extracted data. Supports connections to Fusion via web services.	✅ Low-cost option with enough capacity   ✅ Allows direct “hot” connection to Fusion   ❌ Heavy programming effort required   ❌ Complex coding for transformations
Data Migration Tools (e.g., CloudMigrate By DataFusing)	Use a specialized tool with a UI layer on top of Oracle Autonomous Database. Apply migration rules through drag-and-drop instead of coding.	✅ Minimal coding required   ✅ Easy drag-and-drop rule creation   ✅ Direct hot connection with Fusion   ✅ Speeds up migration and reduces errors   ❌ Licensing/tool cost may apply

You Can Read: Top Methods to Debug Oracle BI Publisher Error Quickly

Pre-Validation & Transformation of Data 

Before loading data into Fusion, you must make sure the data is valid. Bad data in EBS will only create errors with Oracle Import programs.  

Pre-Validate the Data 

The goal of pre-validation is to catch issues before sending data to Oracle Fusion for import. This ensures consistent error reporting and smoother loads. 

Type	Description	Example & Fix
Field Validation	Ensure data types match Fusion requirements, mandatory fields are filled, and values meet length/format rules.	Example: Address Line 1 exceeds the allowed character limit.   Fix: Adjust migration routines to apply transformations (e.g., truncation, formatting) or set default values.
Referential Integrity	Validate relationships within files and across files to ensure consistency.	Example: An invoice line exists in the Invoice Line file, but the referenced invoice is missing in the Invoice Header file.   Fix: Correct the extract routine and re-extract consistent files.
Lookup Validation	Check values against Oracle Fusion lookups by importing reference data into the staging area.	Example: Employee marital status in source is “Domestic Partner,” but Fusion only allows “Single” or “Married.”   Fix: Either update Fusion configuration or create a mapping table from source values to Fusion-accepted values.

Transforming the Data 

Title	Use Case
Apply Default Value	Set a predefined value during migration.   Example: Assign the legislation code of all employees to the United Kingdom.
Rule-Based Transformation	Apply systematic rules to modify data values.   Example: Convert all customer names to uppercase before loading into Fusion.
Apply Mapping	Use lookup tables to map source system values to Fusion-accepted values.   Example: Marital status codes differ between EBS and Fusion. A mapping table converts EBS values into Fusion-compatible values for use in HDL/FBDI files.
Fusion-Based Transformation	Use reference data from Fusion after an initial load to populate dependent fields.   Example: For invoice migration, if the extract contains only supplier names but Fusion requires supplier numbers, extract supplier data from Fusion after supplier load, create a lookup table, and populate supplier numbers on the invoice file.

Pro Tip: CloudSQL allows developers to extract data from Oracle Fusion for pre-validation quickly. With a single click, Fusion data can be loaded directly into the staging area, eliminating the need to create and run Oracle BI reports. 

Migration Execution

This is the execution phase, where data is moved from EBS to Fusion. The process is repeated in each migration cycle and requires careful preparation of both the source and target environments. 

Post-Migration Validation & Reconciliation 

After data is loaded in each cycle, thorough validation is essential to ensure business continuity. This step verifies that the migrated data is accurate, reports run correctly, and security is maintained. 

Check Title	Description
Eyeball Checks	Open a few sample records in Oracle Fusion and compare them with E-Business Suite. Even a small number of record checks can uncover issues missed in earlier migration cycles.
Reconcile Full Data	Use SQL queries to extract migrated data and compare it with original extracts using tools like VLOOKUP to ensure completeness and accuracy.
Validate Critical Reports	Run financial, supply chain, and HR reports in Fusion. Verify that results match expectations, prioritizing business-critical reports first.
Transact on Migrated Data	Perform actual transactions such as creating invoices for migrated customers, applying payments to migrated invoices, etc., to confirm data usability.
Check Integrations	Test inbound and outbound interfaces with migrated data to ensure integrations work correctly and data flows as expected.

You Can’t Ignore: 4 Stages of Oracle Fusion Data Migration Reconciliation

Best Practices & Lessons Learned 

Every migration project comes with challenges. Following best practices can help avoid common mistakes and ensure smoother execution. 

Engage Cross-Functional Teams Early 

Involve IT, Finance, HR, BI, and Operations from the start. Early engagement ensures all requirements are captured and reduces surprises during UAT. Regular workshops and business sign-offs help keep everyone aligned. 

Document Mapping, Customizations, and Decisions 

Maintain a data migration RAID log (Risks, Actions, Issues, Decisions). Track all mapping documents, customizations, and migration decisions for future rollouts or audits. 

Plan Rollback/Fallback Paths 

Take a clone of the Fusion environment before significant data loads. If something goes wrong, you can restore from the backup instead of restarting the process. 

Avoid Migrating Unnecessary Data 

Only migrate historical data if truly needed. Often, archival solutions are better for old or closed transactions, reducing effort and risk. 

Keep Downtime Minimal 

Schedule cut-over windows during weekends or periods of low business activity. If possible, separate master data and transactional data migrations to minimize disruption. 

Must Read: Complete Guide to Oracle BI Publisher Performance Tuning

Frequently Asked Questions (FAQs)