Why EBS Customisations Cannot Move to Oracle Fusion Cloud

Oracle E-Business Suite was built on a technology stack from the early 1990s. The application layer runs on Oracle Forms and Reports, with business logic implemented in PL/SQL stored procedures, Oracle Workflow, and custom database triggers. Oracle Fusion Cloud Applications are built on a completely different architecture: RESTful APIs, Oracle JET for the front end, and a cloud-native data model that shares almost no structural similarity with EBS schemas. When organisations begin their EBS to cloud migration, they discover immediately that no automated path exists to migrate customisations. Every single custom object must be evaluated, redesigned, and rebuilt from scratch within the Fusion paradigm — or retired entirely.

This is not a limitation Oracle publicises prominently during the sales cycle. By the time most organisations understand the full scope of customisation remediation, they have already signed a cloud agreement and committed to a migration timeline. The Oracle EBS licensing complete guide documents the full support lifecycle, but the customisation problem is a programme delivery risk that operates independently of licensing strategy. Understanding it before you negotiate your cloud contract gives you meaningful leverage over implementation scope, phasing, and commercial terms.

Inventorying Your EBS Customisations: Where to Start

Most organisations underestimate their customisation footprint by 40 to 60 percent. The reason is simple: customisations accumulate over many years and many different teams, and no single person has a complete picture of what has been built. A rigorous inventory requires examining Oracle Forms personalisation layers, custom Forms built from scratch, PL/SQL packages and procedures sitting outside standard Oracle schemas, Oracle Workflow modifications, custom concurrent programmes, modified seeded reports, and integration points built using Oracle Database links or bespoke middleware.

The starting point is an automated scan of the CUSTOM schema and any non-standard schemas in your database. Oracle provides a set of scripts through My Oracle Support that can identify modified base objects, but these tools are not exhaustive. Many organisations hold customisations in application top directories on the application server tier that are invisible to database-level scanning. Given the timeline pressure created by EBS end of life in December 2027, starting this inventory in 2025 rather than 2026 substantially improves your ability to make informed decisions about scope and sequencing.

The Three Decisions: Rebuild, Retire, or Re-Platform

Once you have a complete customisation inventory, each item must be categorised against one of three strategic responses. This classification exercise is the most important analytical work in any EBS migration programme, and it drives a disproportionate share of total cost and timeline.

Retire

In our experience across more than 500 Oracle engagements, between 30 and 50 percent of EBS customisations can be retired entirely. Many were built to address deficiencies in older EBS releases that have since been resolved in standard Oracle functionality. Others represent workarounds for long-gone business processes or reporting requirements that no longer exist. Before any rebuild decision is made, the business case for each customisation should be challenged. The question is not "can we rebuild this?" but "do we still need this capability at all?"

Rebuild in Fusion

Customisations with clear, ongoing business value need to be rebuilt within the Fusion paradigm. In practice, this means re-expressing the business requirement using Oracle Fusion's extensibility tools: the Application Composer for object and page extensions, Oracle Integration Cloud for external integrations, Oracle Analytics Cloud for custom reporting, and Oracle BPM Workflow for process automation. None of these are direct replacements for the EBS equivalents. Rebuilding a moderately complex EBS workflow in Fusion can take several weeks of specialist effort. Rebuilding a highly complex custom Oracle Form with significant PL/SQL business logic can take months. The true cost of EBS to cloud migration is almost always driven by the rebuild scope, not the licensing cost.

Re-Platform or Extract

Some customisations are better addressed by extracting the underlying capability into a standalone application, a data warehouse, or a specialist point solution rather than rebuilding it within Fusion. If a custom EBS module has grown into a mission-critical system in its own right, forcing it into Fusion's extensibility framework may create constraints that make the rebuilt version less capable than the original. In these cases, Oracle Integration Cloud combined with a best-of-breed SaaS solution is often a more pragmatic path than Fusion extension development.

IP Ownership: What You Own, What Oracle Owns

A question that arises in almost every migration engagement is whether the organisation owns the intellectual property embedded in its EBS customisations. The legal position is clear but frequently misunderstood. Oracle owns the base application code. Your organisation owns the custom code that sits on top of it, subject to Oracle's licence agreement terms governing derivative works. However, the practical implication is nuanced: your custom PL/SQL that calls Oracle's standard APIs may contain dependencies on Oracle-proprietary data structures and logic. Moving that code outside Oracle's ecosystem requires a careful review to ensure you are not inadvertently reproducing Oracle-proprietary elements.

Where this becomes commercially relevant is in the post-migration period. If your organisation retains an on-premises EBS environment alongside Fusion — even for a transitional period — Oracle will argue that both environments require active licence coverage. Understanding how Oracle audits hybrid running states is critical. Our Oracle licence audit defence playbook covers the specific risks that arise during migration transition periods when parallel environments are operating. The EBS R12.2 extended support cost analysis is also relevant here, since many organisations opt for extended support precisely to preserve a transition runway.

How Customisation Complexity Affects Your Migration Budget

Oracle's standard EBS to Fusion migration estimates assume a lightly customised environment — typically defined as fewer than 200 custom objects and no significant modifications to core financial flows. For most established EBS deployments, this baseline is wildly optimistic. Organisations with 500 to 1,000 custom objects and deep integrations to third-party systems should expect customisation remediation to represent 35 to 50 percent of total programme spend. For the heaviest deployments, custom code management can drive 60 percent or more of project cost.

The implication for budget planning is significant. An EBS migration that Oracle's sales team quotes at $12 million based on a clean lift-and-shift assumption may realistically cost $18 to $22 million once full customisation remediation is scoped. The gap between Oracle's commercial estimate and the true programme cost is one of the most consistent findings across the EBS migration cost analyses we conduct. Organisations that commission an independent assessment before agreeing to an implementation contract are significantly better positioned to negotiate realistic scope, price, and risk allocation.

Customisation Risk During the Extended Support Window

If your organisation is considering Oracle EBS Extended Support — which runs from December 2027 through approximately December 2030 — the customisation question does not disappear. Under Extended Support, Oracle continues to issue security patches and error corrections for the base application, but those patches must be applied to your customised environment. If your custom code modifies standard EBS objects that are patched by Oracle, the patch application process can break your customisations. This creates a recurring maintenance burden that is entirely absent from Oracle's support cost calculations.

Heavily customised EBS environments frequently face patch application failures in test environments that consume weeks of remediation effort before patches can be applied to production. For organisations with large customisation footprints, the actual cost of maintaining an EBS environment through the extended support period is considerably higher than the headline 10 to 20 percent fee uplift described in our EBS extended support cost analysis. Factor this maintenance overhead into any extended support versus migration cost comparison.

The Customisation Inventory as a Commercial Asset

Counterintuitively, a thorough customisation inventory strengthens your commercial position in Oracle negotiations rather than weakening it. Oracle's implementation partners and Oracle Consulting Services price heavily customised migrations at a significant premium. Knowing your exact customisation scope — and being able to challenge Oracle's assumptions about what standard Fusion functionality addresses — prevents padding of implementation estimates. It also provides a factual basis for negotiating extended implementation timelines, which translates directly into more favourable payment phasing in cloud subscription agreements.

The white paper available at our Oracle EBS migration guide covers the full commercial framework for EBS to Fusion negotiations in detail, including how to structure phasing clauses and how to protect your organisation if Oracle's standard Fusion capabilities do not meet requirements that were promised during the sales process. The EBS customisation problem is ultimately a programme governance issue as much as a technical one, and addressing it with the right commercial protections in place is as important as any technical decision.