Oracle EBS to Cloud Migration: The Definitive Guide for 2026

Updated July 2026.

Migrating Oracle E-Business Suite to the cloud means one of two things: a lift-and-shift of EBS onto Oracle Cloud Infrastructure (OCI), or a re-implementation onto Oracle Fusion Cloud ERP. Most enterprises ultimately take the Fusion path — a 12–36 month re-implementation, frequently accelerated by Oracle's Soar programme — while some move to OCI first to buy planning time.

Oracle E-Business Suite (EBS) is one of the most widely deployed enterprise ERP platforms in the world, with tens of thousands of organisations running it globally. Many have run EBS for 10–25 years. Oracle now provides Premier Support for EBS 12.2 through at least 2037 under its Continuous Innovation model — but no new EBS release is planned. The strategic direction is unambiguous: the future is Oracle Fusion Cloud.

This creates a defined migration horizon for EBS customers. Some are planning transitions immediately to gain cloud capabilities; others are extending EBS as long as possible before migrating. All need a clear-eyed view of what migration actually involves.

This guide covers every aspect of the EBS-to-Cloud migration: the two meanings of "cloud," the available paths, realistic timelines, true costs, customisation rethinking, data migration, Oracle's Soar programme, and the decision framework for timing your migration.

---

"Cloud" Means Two Different Things

Before scoping anything, decide which migration you are actually doing. "Move EBS to the cloud" is used interchangeably for two very different projects with different tools, costs, and outcomes:

Both are legitimate. Many enterprises sequence them — OCI first to kill data-centre risk, Fusion later for functional transformation. The rest of this guide focuses primarily on the Fusion re-implementation, since that is where cost, risk, and business change concentrate. See the Oracle ERP Cloud overview for the destination platform and Oracle E-Business Suite for the source system.

---

EBS End-of-Life Timeline

Understanding Oracle's support roadmap is the foundation of your migration planning:

Key implication: Organisations on EBS 12.2 are not facing an imminent support cliff — Oracle has repeatedly extended Premier Support (2033 → 2034 → 2036 → at least 2037) and reviews it annually. The urgency of migration is therefore driven by competitive and capability considerations, not a hard deadline. However, waiting until the mid-2030s to begin planning is not advisable: complex EBS environments require 3–5+ years of planning, implementation, and stabilisation, and Oracle's most attractive commercial incentives are tied to migrating earlier rather than later.

---

Why EBS Customers Are Migrating Now

Even with support secured into the late 2030s, EBS organisations are initiating migrations for several concrete reasons. In most cases it is a combination — rarely a single trigger — and the decision is usually forced by a business event (an acquisition, a hardware refresh, a leadership change) rather than the support roadmap. The five drivers below, in rough order of how often they appear as the deciding factor, are what advisers see most:

1. Competitive Disadvantage from Stale Technology

Oracle Fusion Cloud receives quarterly updates with new AI capabilities, embedded analytics, and process automation. EBS 12.2 receives security patches and tax/legal updates but no new functional capabilities. Companies on EBS are falling behind peers on AI-assisted financial close, intelligent procurement, and real-time supply chain visibility — gaps that widen with every quarterly Fusion release the organisation does not receive.

2. Integration and Data Platform Modernisation

Modern data architectures — cloud data lakes, real-time analytics, event-driven and API-first integration — are dramatically easier to implement against Fusion's modern REST/OIC surface than against EBS's ageing database-centric integration patterns (interface tables, concurrent programs, custom PL/SQL). Companies trying to stand up a data platform, embedded analytics, or a customer/vendor 360 alongside EBS face significant complexity, brittle nightly batch jobs, and duplicated reconciliation logic. Fusion's published business events and REST APIs remove much of that plumbing, which is why a data or analytics initiative frequently becomes the tipping point for the ERP migration itself.

3. Talent and Skills Shortage

Oracle EBS technical skills — particularly DBA expertise for Oracle E-Business Suite, Oracle Forms/Reports development, and RICE (Reports, Interfaces, Conversions, Extensions) development — are increasingly difficult and expensive to hire. The talent pool is ageing; universities don't teach EBS skills. Fusion uses modern development frameworks (VBCS, REST APIs, JavaScript) with larger talent pools.

4. Infrastructure Cost and Risk

Customers running EBS on-premise carry hardware refresh cycles, data-centre and colocation costs, patch-management overhead, DR/business-continuity obligations, and end-of-life risk on the underlying database and operating system. An impending hardware refresh — a five- or six-figure capital outlay to replace servers running a system Oracle no longer enhances — is one of the most common concrete triggers for the migration decision. Moving to OCI (via EBS Cloud Manager or a full Fusion migration) converts that capital expense to subscription, removes the refresh cycle, and shifts patching and availability to Oracle, which is why many organisations do the OCI lift-and-shift first even when Fusion is the eventual destination.

5. Acquisition and M&A Activity

Acquiring a company, being acquired, or carving out a division often accelerates the migration decision. Integrating a new subsidiary into a heavily customised EBS instance requires bespoke technical work and chart-of-accounts surgery; onboarding it into Fusion can leverage standard configuration and Fusion's multi-entity model. Private-equity owners in particular frequently mandate a move off EBS to standardise a portfolio, improve reporting visibility, and lift exit valuation — making an ownership change one of the strongest single predictors of an imminent migration.

---

Migration Path Options

There are four primary migration paths from EBS to Oracle Fusion Cloud, each with different risk, cost, and timeline profiles. The right path depends on how customised your EBS is, how much business-process change you can absorb, and how much infrastructure or M&A pressure you are under. This table summarises the trade-offs; each path is detailed below.

Path 1: Full Reimplementation (Clean-Sheet Implementation)

Treat the Oracle Fusion deployment as a new implementation. Build Fusion from scratch using Oracle's embedded best practices. Migrate only master data and open transactions from EBS; leave historical data in an archive.

Best for: Organisations where EBS is heavily customised, business processes have evolved significantly since original EBS implementation, or where the strategic goal is substantial business transformation alongside the technology change.

Pros: Clean break from legacy debt; opportunity to adopt Oracle best practices; lowest long-term maintenance cost; modern architecture from day one.

Cons: Highest implementation cost; longest timeline; maximum disruption; requires parallel EBS operation during transition.

Path 2: Lift-and-Shift (Config-Equivalent Migration)

Map EBS configuration directly to Oracle Fusion equivalents. Carry forward the logic of existing EBS setup (chart of accounts, business units, workflows) into Fusion's architecture.

Best for: Organisations with relatively standard EBS implementations, limited customisation, and a desire to minimise process change during the migration.

Pros: Faster timeline; lower disruption; familiar processes for end users; lower cost.

Cons: May carry forward inefficient EBS processes; misses opportunity for business transformation; some EBS config doesn't map cleanly to Fusion architecture.

Path 3: Phased Migration (Module by Module)

Migrate from EBS to Fusion one functional area at a time. Typical sequence: Financials first, then Procurement, then SCM/Manufacturing, then HCM.

Best for: Large, complex EBS environments where doing everything simultaneously is too risky; organisations with internal resource constraints; situations where certain modules have unique complexity requiring focused attention.

Pros: Risk managed phase-by-phase; can learn and adjust; budget spread over multiple years; earlier value realisation for early phases.

Cons: Extended parallel operation of EBS and Fusion; integration complexity during multi-year transition; programme management overhead; total cost often highest.

Path 4: Oracle-Managed Subscription (Move to OCI, Defer Application Upgrade)

Move EBS from on-premise or third-party hosting to Oracle Cloud Infrastructure (OCI) without upgrading the application, using EBS Cloud Manager to automate the rehost. Run EBS 12.2 on OCI managed infrastructure while planning the Fusion migration separately.

Best for: Organisations needing to eliminate on-premise infrastructure immediately (an imminent hardware refresh, a data-centre exit) while having more time to plan the Fusion migration.

Pros: Eliminates data-centre cost and hardware-refresh capital outlay quickly; buys planning time; Oracle manages infrastructure; typically reported ~30% performance gain vs. ageing on-prem hardware; qualifies for Oracle's commercial programmes.

Cons: Does not solve the functional gap between EBS and Fusion; delays full cloud transformation; still requires a full Fusion migration project later, so total programme cost is higher than a single direct move.

---

Oracle Soar: Oracle's Migration Acceleration Programme

Oracle Soar (Simplified Oracle Application Rationalisation) is Oracle's structured programme for helping EBS (and PeopleSoft) customers migrate to Fusion Cloud. It packages a methodology, automated tooling, and commercial incentives into a single motion, and is the framework most Oracle-led migrations are run through. It includes:

Soar Methodology

A phased migration approach with defined workstreams:

1. Assess: Current-state EBS analysis; gap identification; migration scope definition
2. Prepare: Environment setup; data profiling; integration architecture design
3. Migrate: Data migration; configuration build; customisation rationalisation
4. Validate: Testing (UAT, regression, performance); parallel run; cutover planning
5. Operate: Hypercare support; stabilisation; ongoing optimisation

Soar Tools and Accelerators

Oracle provides specific technical tools under Soar:

Soar Commercial Benefits

Oracle typically offers commercial incentives to Soar-participating customers, and these are often the single biggest lever on net migration cost:

• Conversion / licence credits: Oracle commonly bundles a 25–40% conversion credit into Fusion deals signed ahead of an EBS support event, crediting existing EBS licence and support spend toward the Fusion subscription
• Implementation credits: OCI credits applied to implementation and migration workloads
• SI subsidies: Oracle may partially fund system-integrator implementation costs for strategic migrations
• Preferential pricing: Soar customers often receive better multi-year terms on Fusion modules
• "Shelving Right": some customers negotiate a clause to stop paying EBS support fees on shelved on-prem licences during the transition, reducing dual-run cost

These benefits are negotiated individually; the value varies significantly by account size, migration complexity, timing, and competitive situation. Because they are time-sensitive and tied to Oracle's fiscal calendar, they are best negotiated with the Fusion subscription itself — see Oracle ERP Cloud pricing for how the subscription is structured.

---

What Happens to EBS Customisations?

This is often the most complex and most underestimated aspect of EBS-to-Fusion migrations. Large EBS environments can have hundreds or thousands of customisations built up over 10–20 years, and the effort to remediate them is frequently the largest single line in the implementation budget.

Types of EBS Customisations

Customisation Rationalisation Process

Before migration, perform a customisation inventory and rationalisation:

1. Inventory: Document every customisation — who uses it, how frequently, what business need it serves
2. Assess: For each customisation, determine: Does Fusion standard functionality cover this? Does it need rebuilding? Can it be eliminated?
3. Categorise:
   • Standard: Covered by Fusion out of the box — no migration needed
   • Rebuild: Business need is valid; must be rebuilt in Fusion extensibility
   • Eliminate: No longer used or business process redesign makes it unnecessary
   • Defer: Needed but not on Day 1; plan for Phase 2
4. Estimate: Cost and timeline for each rebuild item

Typical finding: 30–50% of EBS customisations can be eliminated (the business process they supported has changed, or Fusion standard covers it). 30–50% are rebuilt in Fusion's extensibility framework. 10–20% require significant design work to translate to Fusion's architecture.

Cost of Customisation Remediation

Customisation rebuilding typically represents 30–50% of total implementation cost in complex EBS migrations — often the largest single cost category after core system-integrator fees. A 500-customisation EBS environment can generate £2.4M–£6.4M in customisation remediation work alone, and the range is wide because the driver is not the raw count but the mix: a handful of deeply embedded Oracle Forms screens or bespoke PL/SQL pricing engines can cost more to rebuild than hundreds of simple report personalisations. This is why a full customisation audit (see Challenge 2 below) belongs in the first project workstream, before implementation scope and cost are fixed — organisations that price the project before auditing customisations are the ones that overrun.

---

Data Migration Strategy

What Data to Migrate

Data Quality Requirements

EBS databases often contain years of data quality issues — duplicate records, inactive items, inconsistent naming, missing fields. Data cleansing is a significant workstream:

• Timeline: 3–6 months for thorough data profiling, cleansing, and validation
• Tools: Oracle Enterprise Data Quality, Informatica, Talend, or custom SQL scripts
• Effort: Typically 10–20% of total implementation effort

Data Migration Technical Approach

Oracle's standard EBS-to-Fusion data loading uses FBDI (File-Based Data Import) and REST APIs:

1. Extract from EBS using Oracle's seeded extract programs or custom SQL
2. Transform using ETL tools (Oracle Data Integration, Informatica, or custom)
3. Validate in a staging environment
4. Load using FBDI templates (for mass loads) or REST APIs (for incremental)
5. Reconcile loaded data against EBS source

---

Timeline and Cost Benchmarks

Timeline by Organisation Size

Cost by Organisation Size

Implementation Cost Breakdown (Typical)

The Hidden Cost: Dual-Run During Transition

The benchmarks above understate one line that catches many programmes by surprise: the cost of running EBS and Fusion in parallel during the transition. Until cutover, you keep paying EBS support and infrastructure while also paying the Fusion subscription and the implementation team. Advisory analyses have put an 18-month overlap at roughly £5M+ above the pre-migration baseline for a large enterprise — a several-hundred-percent spike in run cost during the window. This is precisely what the Soar conversion credit and "Shelving Right" clause are designed to blunt, and it is why minimising parallel-run duration (Challenge 6 below) has a direct, quantifiable payoff.

---

Common Challenges and How to Avoid Them

Challenge 1: Scope Creep

EBS migrations frequently expand in scope as process analysis reveals complexity that wasn't anticipated. A Financials migration that was scoped for 6 months grows to 18 months as consolidation complexity, multi-GAAP requirements, and integration rebuilds are fully understood.

Mitigation: Invest in thorough upfront discovery — 2–3 months of assessment before fixing scope. Build contingency into every timeline. Use a phased approach for large environments to contain scope per phase.

Challenge 2: Customisation Volume Surprise

Organisations often underestimate the number and complexity of EBS customisations. A company that believes it has "minimal customisations" sometimes discovers 400+ RICE objects during assessment.

Mitigation: Conduct a full customisation audit as the first project workstream. Use Oracle's Migration Assessment tool to auto-scan the EBS database for custom objects. Rationalise before scope-fixing implementation cost.

Challenge 3: Chart of Accounts Design

The COA migration is a critical architectural decision. Oracle Fusion's COA structure (segments, value sets) differs from EBS's flexfield structure. Organisations sometimes try to map EBS COA directly to Fusion, then discover that the Fusion segment model doesn't support their reporting requirements.

Mitigation: Engage a financial architect for COA design before any other configuration. Validate the proposed COA against all reporting requirements (management reporting, statutory reporting, consolidation, segment reporting) before committing.

Challenge 4: Integration Rebuilds

EBS has typically built up 10–30+ integrations with third-party systems (bank connectivity, tax engines, HR systems, manufacturing execution, etc.) These must all be rebuilt via Oracle Integration Cloud (OIC) or equivalent middleware.

Mitigation: Inventory all integrations early. Prioritise for go-live vs. post-go-live. Oracle Integration Cloud has pre-built adapters for many common systems; use them rather than building from scratch.

Challenge 5: Change Management

EBS users who have worked in the same system for 10–20 years face significant change. Process redesign means some familiar workarounds disappear. New UI is unfamiliar.

Mitigation: Begin change management planning in month 1. Assign business super-users to the project team. Invest in hands-on training in Fusion sandbox environments. Plan for a 3–6 month hypercare period post-go-live.

Challenge 6: Parallel Run and Cutover Complexity

Running EBS and Fusion simultaneously during parallel run, then cutting over, is operationally complex — particularly for month-end close, which may need to happen in both systems — and, as noted above, is where the largest hidden dual-run cost accrues.

Mitigation: Minimise parallel run duration (4–8 weeks maximum). Invest in automated reconciliation tooling between EBS and Fusion during parallel. Plan cutover on a weekend at month-end for cleanest break.

---

Decision Framework: Timing Your Migration

Migrate Immediately if:

• Your EBS version is 12.1 or earlier (Premier support ended 2021; Extended ended 2024)
• Infrastructure is ageing (hardware refresh due in 1–2 years)
• Competitive disadvantage from lack of AI/cloud capabilities is affecting business performance
• Finance team is supplementing EBS with extensive Excel-based processes
• You are post-acquisition and need to consolidate to a single platform
• Oracle is offering significant commercial incentives that expire within 12 months

Migrate Within 3 Years if:

• On EBS 12.2 but running custom integrations that will need modernisation regardless
• Supply chain or manufacturing capabilities are limiting growth
• Recruiting struggles due to EBS skill scarcity are affecting operations
• Planning is ongoing — use this time for thorough assessment and partner selection

Stay on EBS (Temporarily) if:

• On EBS 12.2, heavily customised, no immediate competitive pressure (Premier Support runs to at least 2037)
• Major organisational change (M&A, restructuring) creating instability
• ERP team is not staffed for a major transformation
• Use the time to reduce customisation debt and prepare for a cleaner migration

---

Frequently Asked Questions

When does Oracle end support for EBS 12.2?

Oracle provides Premier Support for Oracle E-Business Suite 12.2 through at least 2037 under its Continuous Innovation model, and reviews the date annually — it has already been extended from 2033 to 2034 to 2036 to at least 2037. This includes security patches, regulatory and tax updates, and cumulative annual application updates. Functional enhancements have effectively stopped for EBS — Oracle's genuinely new capabilities are developed exclusively for Oracle Fusion Cloud. So while EBS 12.2 is supported into the late 2030s, staying on it means missing every new Fusion capability in the meantime.

How much does an EBS to Oracle Fusion migration cost?

Costs vary enormously based on organisation size and complexity. Small organisations (under 500 users, minimal customisations) can complete migrations for £2.4M–£6.4M total (software + implementation). Mid-enterprise organisations (500–5,000 users) typically spend £6.4M–£20M. Large enterprises (5,000+ users, 50+ entities) can spend £20M–£80M+. Two factors move the number the most: customisation remediation (30–50% of implementation cost) and dual-run overlap. Oracle conversion credits of 25–40% can materially reduce the net figure. The most reliable way to estimate your specific cost is a structured migration assessment.

How long does an Oracle EBS to cloud migration take?

An OCI lift-and-shift (rehosting EBS with EBS Cloud Manager, no application change) typically takes 3–9 months. A Fusion Cloud re-implementation typically takes 12–36 months depending on size and path: 12–18 months for a small, standard environment; 18–36 months for a mid-to-large enterprise; and 36–60+ months for a phased programme across a very large, complex EBS footprint. Complex environments should budget 3–5+ years end to end including planning and stabilisation.

Can I migrate EBS data to Oracle Fusion, or do I start fresh?

Both approaches are valid. Most organisations migrate master data (customers, vendors, items, employees), open transaction data (open AR/AP, open POs, active projects), and 2–3 years of summary GL history. Full historical transaction detail is typically not migrated — it's maintained in an EBS read-only archive for reference. Starting completely fresh (no data migration) is rare but occasionally chosen by organisations wanting a complete clean break.

What is Oracle Soar and do I need it?

Oracle Soar is Oracle's migration methodology and tooling programme for moving from EBS (and PeopleSoft) to Oracle Fusion Cloud. It includes pre-built migration tools, accelerators, and commercial incentive structures (including conversion credits). Participation is not mandatory — you can implement Fusion without it — but Soar often provides real commercial and technical value, particularly the pre-built data migration templates and access to Oracle's incentives. Discuss Soar participation with your Oracle account team early in planning.

Will my EBS customisations work in Oracle Fusion?

No — EBS customisations do not carry over. Oracle Forms screens, RICE objects, custom PL/SQL, Workflow customisations, and OAF personalisations must all be rebuilt using Fusion's modern extensibility tools (VBCS, OIC, Oracle Analytics/OTBI). In practice 30–50% of customisations are eliminated because Fusion standard functionality covers them or the underlying process has changed, 30–50% are rebuilt, and 10–20% need significant redesign. A customisation audit up front is essential to size this accurately.

Should I migrate EBS to OCI first, then to Fusion later?

This is a valid two-stage strategy. Moving EBS to OCI (Path 4 above) eliminates infrastructure risk quickly — hardware refresh, data-centre cost — while the Fusion migration is planned, and Oracle provides Oracle Cloud Lift and EBS Cloud Manager to assist. The caveat is that it extends total programme duration and cost: you are effectively doing two projects. For organisations with immediate data-centre or hardware-refresh pressure, the two-stage approach is sensible; for those without near-term infrastructure risk, a direct Fusion implementation is usually more cost-effective.

---

Next Steps

The EBS-to-Fusion migration is one of the most significant technology investments an enterprise can make. The organisations that approach it with thorough planning, realistic timelines, and strong implementation partners consistently outperform those that rush to go-live. Before you commit budget, define your requirements in detail — it is the single best defence against the scope creep and customisation surprises described above.

Related pages:

• Oracle ERP Cloud Overview
• Oracle E-Business Suite
• Oracle ERP Cloud Implementation
• Oracle ERP Cloud Modules
• Oracle ERP Cloud Pricing
• PeopleSoft to Oracle ERP Cloud Migration
• Oracle ERP Cloud vs SAP S/4HANA
• RISE with SAP (for contrast)