Oracle EBS vs Oracle Fusion: What Changes

Why the EBS-to-Fusion Question Matters Now

If you’re still running Oracle E-Business Suite, the question has shifted. Not whether to move. When — and whether you’ve left yourself enough runway to do it properly.

Oracle ended premier support for EBS R12.1 in 2017. R12.2 premier support ran until 2022 and sits under extended support now, with sustaining support committed beyond that. But sustaining support is a specific, limited thing — critical patches, security fixes. That’s the scope. New features? No. Updated interfaces? No. Deeper integration with modern tooling? Also no.

For finance, HR, and supply chain teams trying to keep pace with how their functions are evolving, that distinction is a real problem.

The roadmap signals are unambiguous. Oracle’s engineering effort is going into Fusion Cloud Applications. Every quarterly update to Oracle Cloud ERP, HCM, and SCM adds capability that EBS users simply don’t get. Organisations on EBS aren’t standing still — they’re falling further behind a platform Oracle is actively building out.

There’s a cost dimension too.

Extended and sustaining support contracts are expensive. And they don’t include the kind of development that makes that cost feel justified. We see this consistently during ERP reviews: organisations paying significant support fees for a system that’s increasingly difficult to integrate with newer technology, harder to staff for as implementation partners redirect their focus to Fusion, and more expensive to customise year over year.

So what makes this genuinely complicated?

The scale of what changes when you move. EBS and Fusion are not different versions of the same product. Different data models, different security frameworks, different approaches to customisation, fundamentally different integration architectures. This is a reimplementation — not an upgrade. Organisations that treat it like an upgrade run into serious problems mid-project. We see it regularly.

That’s the context this article is built around. If your business is still on EBS and you need a clear picture of what moving to Fusion actually involves — technically, functionally, operationally — the sections below cover it in concrete terms. For the higher-level business case, see our full Oracle Fusion vs EBS comparison.

Architecture: From On-Premises Monolith to Multi-Tenant Cloud

Oracle E-Business Suite was built for a world where software lived on servers you owned. Each EBS deployment is a single-instance installation — one database, one application tier, one organisation’s configuration locked into that environment. Your IT team owns everything: hardware provisioning, OS patching, database tuning, backups, disaster recovery.

That control is real. So is the cost.

Oracle Fusion, delivered as Oracle Cloud ERP, works entirely differently. It runs on a shared, multi-tenant SaaS architecture — multiple customers on the same underlying platform, with data and configurations kept logically separate. You do not manage servers, operating systems, or database instances. That responsibility sits with Oracle entirely.

So what does that actually mean in practice?

With EBS, a significant chunk of IT effort goes toward keeping the platform alive. CPU patches. Downtime coordination. Compatibility checks between customisations and new releases. Each major upgrade is effectively its own project — regression testing, custom code review, extended timelines. During technical audits we often see organisations underestimate how much internal capacity this quietly absorbs.

With Fusion, Oracle handles the patching cadence. Updates are applied to the shared platform on Oracle’s schedule, not yours. You still need to test your configurations and extensions against each update — that work doesn’t disappear — but you are not managing the underlying stack.

Less infrastructure control. Lower operational overhead. A platform that stays current without a multi-month upgrade project every few years. That is the trade-off.

The customisation model is structurally different too. EBS allowed direct modifications to application code — common practice at the time, but it made every upgrade harder. Those customisations had to be re-validated or rewritten with each release. Fusion is designed to be configured rather than modified at the code level. Extensions are built using Oracle’s approved toolsets, such as Visual Builder and APEX, and sit outside the core. Oracle’s updates do not break them in the same way.

For organisations working through the comparison at the infrastructure layer, the honest answer is that this is a fundamental change, not an incremental one. Not a software upgrade in the traditional sense.

It is a shift in who owns and operates the platform, how updates reach you, and what your internal teams are actually responsible for. That has real implications — for IT headcount, vendor contracts, and how your business manages risk around system availability. Worth understanding clearly before you start planning.

Data Model and Chart of Accounts: Key Structural Changes

Moving from Oracle EBS to Oracle Fusion isn’t just a data migration. The underlying financial data model is fundamentally different, and the chart of accounts is where that difference causes the most friction.

Set of Books vs. Enterprise Structures

In EBS, the core accounting construct is the Set of Books (renamed Ledger in R12). Each one ties together a functional currency, a calendar, and a chart of accounts. Organisations with multiple legal entities or reporting requirements typically manage this through separate Sets of Books — often held together with complex intercompany configurations and manual reconciliation.

Fusion replaces all of that with the Enterprise Structures framework.

It separates concerns that EBS bundled together. Legal entities, business units, ledgers, and reference data sets are defined independently and linked through a structured hierarchy. A single Primary Ledger can support multiple legal entities. Secondary Ledgers and Reporting Currencies sit alongside it, feeding from the same journal entries — no duplicate entry, no consolidation workarounds.

That flexibility is genuinely useful. But it also means decisions baked into an EBS implementation years ago — decisions that felt permanent — need to be revisited. Often restructured entirely.

Segment Structures and the Accounting Flexfield

EBS uses the Accounting Flexfield to define COA segments. Most implementations land somewhere between five and ten segments: entity, cost centre, natural account, project, product line, and similar dimensions. Flexible by design, but these structures accumulate complexity over time. Segments get added to satisfy reporting requirements. The COA grows.

Fusion takes a similar segment-based approach — but the downstream consequences are more pronounced.

Fusion’s reporting is built around Smart View, OTBI, and Financial Reporting Studio, and those tools perform best when the COA is clean and segment values are well-governed. Bloated or inconsistently structured COAs from EBS become reporting debt in Fusion. See our Oracle Fusion financial reporting guide for how those tools work.

We see this in almost every migration audit.

Ledger Hierarchy and Consolidation

EBS consolidation typically relies on FSG reports, the Global Consolidation System, or third-party tools. A lot of organisations end up running consolidation outside EBS entirely — spreadsheets, Hyperion, or both. It’s a common workaround that becomes load-bearing over time.

Fusion builds consolidation directly into the ledger hierarchy. A Reporting or Consolidation Ledger sits above Primary Ledgers and can automatically aggregate balances, apply eliminations, and handle currency translation.

The tricky part: it only works correctly if the underlying Primary Ledger structure and COA segments are designed with consolidation in mind from day one. If your EBS COA was built incrementally over years — segments and values added as the business grew — it’s unlikely to map cleanly into a Fusion consolidation hierarchy without significant rework.

Balancing Segments and Intracompany Accounting

EBS sets the balancing segment — usually entity or company — at the Accounting Flexfield level. Fusion goes further, supporting three balancing segment types: primary, second, and third. That structure enables more granular intracompany balancing without custom development.

In practice, this only adds value if the segment structure is designed to use it.

Organisations that migrate EBS COAs unchanged typically carry over a single balancing segment and lose the multi-level balancing capability entirely. It’s one of the more common missed opportunities we see during post-migration reviews — straightforward to address in design, expensive to retrofit later.

COA and Fusion Design: What to Audit Before Migration

Before any COA migration work starts, you need a structured review of the existing EBS setup. The checklist below covers the areas that matter most.

The data model differences between EBS and Fusion aren’t surface-level. They reflect a fundamentally different approach to how financial structures are modelled, related, and governed.

Get the COA and Enterprise Structures design right before go-live, and Fusion delivers cleaner reporting and a faster close. Get it wrong, and you’ve rebuilt EBS’s accumulated complexity in a newer system.

The migration itself won’t fix a poorly designed foundation. It just moves it.

Module-by-Module Mapping: EBS to Fusion Equivalents

One of the first practical questions teams ask when planning an EBS-to-Fusion migration is simple: where does my module go?

The answer is rarely clean. Some modules map across neatly. Others have been restructured, merged, or rebuilt around a fundamentally different approach — and if you don’t know which is which before you scope the project, you’ll find out the hard way during design.

Below is a breakdown of the five modules that come up most often in EBS-to-Fusion transitions.

General Ledger

The GL mapping typically demands the most structural rework of any module on this list. In EBS, your chart of accounts is tied to a specific ledger. Cross-ledger reporting means additional configuration through reporting sets or FSG reports. Fusion GL works differently — a single chart of accounts feeds multiple ledgers simultaneously.

If your organisation has multiple legal entities or reporting currencies, that change affects how your accounting structure is designed from day one. Not as an afterthought.

For more detail on what this means in practice, see our overview of Oracle Fusion General Ledger.

Accounts Payable and Accounts Receivable

Both AP and AR have direct counterparts in Fusion. The integration points have shifted, though.

In EBS, AP often depends on third-party scanning or imaging tools sitting outside the core application. Fusion Payables brings document capture and supplier invoice processing into the platform itself. On the AR side, Fusion Receivables connects more tightly to credit, collections, and cash management than EBS did out of the box. Our Oracle Fusion Accounts Payable guide covers the Payables side in detail, and Oracle Fusion Expenses shows how employee spend now flows natively into it.

Teams running customised aging reports or collection workflows in EBS will need to remap that logic to Fusion’s native tooling. Carrying it forward as-is isn’t an option.

iProcurement to Self Service Procurement

This is one of the modules where the functional gap is most visible to end users. The catalog experience in Fusion Self Service Procurement is rebuilt from scratch. Approval hierarchies, purchasing limits, supplier portal integration — all of it works differently.

Organisations that invested heavily in configuring iProcurement, particularly those with complex punch-out catalogs or layered internal approval rules, should treat this as a significant workstream. Not a configuration update.

Details on the Fusion procurement model are covered in our Oracle Fusion Cloud modules overview.

Order Management

The shift here is more significant than it looks on paper.

EBS Order Management is a transactional module — it captures orders and drives fulfilment through shipping and invoicing. Fusion Order Management is built around orchestration. It coordinates fulfilment across multiple systems and channels, including third-party logistics and drop-ship scenarios, using a rules-based fulfilment process.

Organisations with straightforward order flows will adapt quickly. Those running complex pricing, multi-currency transactions, or integrated warehouse management in EBS will need to reassess the entire process model. Not just the configuration.

Getting these mappings right early means your project scope reflects what actually needs to be built. The modules exist in both systems — but the configuration, integration points, and underlying data structures are different enough that treating this as a technical migration rather than a functional redesign is one of the most common causes of scope growth mid-project.

We see it consistently. Teams assume the module is the same because the name is familiar. It rarely is.

Security Model: Responsibilities vs. Role-Based Access Control

EBS access control is built on Responsibilities. Each one is essentially a bundle — menus, functions, and data access wrapped into a named role like “AP Manager” or “GL Super User.” Users get assigned one or more, and that determines what they can see and do.

It works. But it has real problems.

Responsibilities are coarse-grained and hard to audit at any meaningful level of detail. They also accumulate. Someone needs access for an edge case, they get a new Responsibility, and nobody removes it later. By the time most organisations reach a migration project, their EBS security model is years of layered exceptions with little documentation to explain any of it.

Fusion takes a fundamentally different approach with Role-Based Access Control (RBAC). Access is structured in three layers:

• Duty roles — the smallest unit. A specific task or function, like “Manage Supplier Invoices.” Oracle-delivered, mapped to specific application functions.
• Job roles — aggregate duty roles into something that reflects an actual position, like “Accounts Payable Specialist.” Most users are assigned at this level.
• Data security policies — control which records a user can act on. Can an AP Specialist see invoices from one business unit or all of them? This is where that gets defined.

That last layer is the critical difference.

EBS Responsibilities cannot cleanly separate function access from data access. Fusion makes that separation explicit.

Segregation of duties is where this really matters. In EBS, finding conflicts — situations where one user holds two Responsibilities that shouldn’t be combined — means running a GRC tool or doing it manually. We see this constantly during technical audits. Nobody has a clear picture of who actually has what access, or why.

In Fusion, the RBAC structure makes role conflict analysis far more tractable. Oracle ships a pre-built set of SoD policies mapped to common audit requirements. That doesn’t mean Fusion security is automatically clean. It means the architecture gives you the tools to enforce and demonstrate compliance, rather than reconstruct it after the fact.

Fusion’s three-layer RBAC model gives auditors something EBS Responsibilities never could: a clear, policy-driven record of who can do what and to which data.

Here’s the practical point that catches most migration teams off guard: you cannot directly translate EBS Responsibilities into Fusion job roles. The underlying function model is different. A one-to-one mapping will either over-provision access or leave gaps — sometimes both, in different parts of the system.

So what’s the right approach? Start from the business process. What does this person actually do? Then build job roles from the appropriate Oracle-delivered duty roles. For organisations with heavily customised EBS security, this role design work is often more effort than the technical migration itself.

Data security policies also require design decisions EBS organisations have never had to make explicitly. In EBS, data access is mostly controlled by operating unit assignment and org hierarchy — implicit, baked in. In Fusion, you define it: the object (invoice), the action (view, edit), the condition (business unit = BU001). More flexible, but it requires deliberate configuration.

Leave data security policies at their defaults and you’ll likely end up with broader access than anyone intended.

For teams working through role design and SoD compliance ahead of a migration, our Oracle Fusion security and compliance guide covers the structural decisions and common pitfalls in more depth.

The shift from EBS Responsibilities to Fusion RBAC isn’t a re-configuration exercise. It’s a chance to rebuild your access model against what people actually do and what your compliance requirements actually are. Organisations that treat it as a straight migration — map old to new, move on — tend to carry the same security problems straight into the new system.

Integration and Extensibility: APIs, OIC, and Custom Objects

How you connect Oracle to the rest of your stack is one of the sharpest practical differences between EBS and Fusion. These two systems were built in different eras, with different assumptions about how enterprise software communicates.

That shows clearly when you get into the detail.

EBS: RICE Objects and Point-to-Point Integration

EBS customisation has long run on what Oracle developers call RICE objects: Reports, Interfaces, Conversions, and Extensions. Built directly in the database layer using PL/SQL, Oracle Forms, and Oracle Reports. Capable, yes — but the custom logic is tied tightly to the application schema, and that creates a maintenance problem that compounds over time.

Every time Oracle releases a patch bundle, custom RICE objects can break.

Regression testing, rework, delay before the patch can safely go in. We see this constantly during technical audits — teams sitting on years of accumulated RICE debt that nobody wants to touch. A heavily customised EBS environment becomes genuinely difficult to change, not because of the technology itself, but because of everything layered on top of it.

On the integration side, EBS relies on database-level APIs, Oracle Business Events, and SOAP-based web services. Connecting EBS to a third-party system typically means building point-to-point interfaces and then owning them indefinitely. There’s no standard, governed API catalogue. Knowledge of which internal APIs exist — and how they actually behave — usually lives with a small group of senior technical staff. When those people leave, it gets complicated.

Fusion: REST APIs and a Governed Extensibility Model

Fusion publishes a comprehensive library of REST APIs across all its modules. Versioned, documented, and maintained by Oracle as part of the standard product. Any external system — a CRM, a payroll engine, a custom-built internal tool — can connect via standard HTTP calls.

That’s a meaningful shift in what integration work actually costs.

With EBS, equivalent connections often required custom database-level code that your team owned and maintained. With Fusion, you’re working with documented, stable endpoints that Oracle keeps current. Beyond REST, Fusion also supports SOAP web services for legacy compatibility, plus file-based data import (FBDI) for bulk loads. Multiple well-documented routes in and out of the system, without writing custom database code.

Oracle Integration Cloud (OIC)

OIC is Oracle’s managed integration platform — the recommended way to connect Fusion to external systems. Pre-built adapters for Fusion modules, common SaaS applications, and on-premises systems. Orchestration, error management, and monitoring handled through a visual interface.

Because OIC runs as a managed service, Oracle handles availability and platform maintenance. Your team focuses on business logic, not infrastructure.

For organisations running a phased migration — where EBS and Fusion operate in parallel — OIC includes adapters for EBS. That makes it useful during transition, not just at the end of it.

Fusion’s Extensibility Sandbox

Where EBS customisation happens directly in the codebase, Fusion gives you a structured extensibility layer: Application Composer and Page Composer. Custom objects, custom fields, custom business rules — all built inside a sandbox environment, tested there, then promoted to production. Stored separately from Oracle’s own application code.

That separation is the key thing.

When Oracle releases a quarterly update, sandbox extensions are not overwritten. Custom logic survives without manual rework. A common mistake we see is teams underestimating how much of their EBS workload is just keeping customisations alive through patching cycles — weeks of regression testing before a patch can safely go in. Fusion’s model removes that burden entirely.

Custom objects built in Application Composer can be linked to standard objects, given their own workflows, and exposed via the same REST API framework as standard modules. They behave like a proper part of the system. Not a bolt-on.

What This Means for Teams Moving From EBS

The shift from RICE-based development to Fusion’s extensibility model isn’t just technical. It’s a change in how your development team thinks about customisation. Developers who built their careers on PL/SQL and Oracle Forms need to reskill toward REST, low-code configuration tools, and integration platform concepts.

For teams with large EBS customisation estates, that’s not a minor adjustment.

Audit your RICE objects early. Don’t leave it until the migration is underway.

Some objects will map directly to standard Fusion functionality and can simply be retired. Others will need to be rebuilt as sandbox extensions or replaced with OIC integration flows. A small number won’t have a clean equivalent — and those will force genuine design decisions. Not about how to rebuild them, but about whether the underlying business requirement still makes sense at all, or whether it’s a process that should change rather than be replicated.

Frequently Asked Questions

Ready to Assess Your Migration Path?

You might also find helpful