What happens to your EBS customizations when you move to Fusion

The single most consequential fact in an EBS to Fusion migration is also the one most consistently underplayed in the sales cycle. Your Oracle EBS customizations do not move. Not the OAF personalizations, not the Oracle Forms screens, not the custom PL/SQL, not the RICE objects, not the Workflow customizations. Fusion is a different product with a different extensibility model, and every non standard piece of your EBS estate has to be either rebuilt in Fusion's own tooling, replaced by standard functionality, or deliberately retired. This is the part of the move that decides the budget, the timeline and, honestly, whether the programme succeeds.

This article is written for EBS technical teams and heads of applications who have been told, or are about to be told, that Fusion is the natural next step. It is the plain version of what actually happens to your custom layer, category by category, so that whatever you decide next, you decide it with the real picture. We work across the GCC, in Saudi Arabia, the UAE and Qatar, and across the US, UK, Europe and Australia, and the shape of this conversation is the same in every market.

Oracle Fusion Cloud Applications are SaaS. That is not a marketing statement, it is an architectural one. In a SaaS product, the customer does not get direct access to the underlying database the way an EBS customer does. There are no custom triggers on standard tables, no PL/SQL running inside the application container, no DML against the seeded data model from your own packages. The extensibility surface is deliberately narrower and it is API centric.

That is why the EBS style of customization cannot be forklifted. The vast majority of what a mature EBS estate calls a customization was built against assumptions that only hold when you own the database. Move to a shared, multi tenant application platform and those assumptions no longer exist. This is not a criticism of either product. It is the mental shift that decides how realistic the migration plan is.

The clearest way to think about a Fusion move is to walk each RICEFW category and be honest about where it lands. This is the part of the assessment where the real cost shows up.

Reports

Custom EBS reports go to BI Publisher and OTBI in Fusion, but against a different data model. The BI Publisher template you already wrote might be portable in shape, the data extract behind it almost never is. Fusion exposes subject areas and reporting views that are not the EBS tables you are used to. Every report is a fresh data mapping exercise, not a lift and shift.

Interfaces

Custom interfaces move to Oracle Integration Cloud, sometimes to FBDI for bulk patterns, and to REST APIs for real time patterns. If you currently have a shell script that drops a file into a directory and a concurrent program that picks it up, none of that survives. The functional intent survives, the implementation is entirely rebuilt on OIC connectors, adapters and orchestrations.

Conversions

One time and repeatable data conversions run through FBDI templates, with ADFdi for row level loads where a spreadsheet interface still makes sense. If your EBS conversion strategy was custom PL/SQL packages writing into interface tables, the target pattern is completely different, and the mapping work is the majority of the effort.

Extensions

This is the category with the most nuance. Fusion offers several extension surfaces. Application Composer covers a class of field, object and page level extensions in CX and adjacent pillars. Visual Builder Cloud Service is the tooling for custom UI applications that plug into Fusion using REST. Page personalization and sandboxes handle configuration level changes without code. Beyond that, Oracle APEX is now a first class option for data heavy internal applications that consume Fusion REST, and recent APEX releases added explicit Fusion integration support in the create application flow. There is more than one right answer here, and the choice depends on the shape of the extension, not on a preferred vendor tool.

Forms

Oracle Forms has no equivalent in Fusion. A custom Forms screen must be redesigned, in Visual Builder if it is a user facing task inside a Fusion process, or in APEX if it is a data heavy operational tool that lives adjacent to Fusion. There is no automated path, because there is no target technology that matches the input.

Workflow

Workflow customizations become Fusion approval rules configured through the standard approvals framework, and BPM where more complex routing is genuinely required. Most Workflow customizations in EBS turn out, on inspection, to be things Fusion approvals can express declaratively, which is good news for the rebuild cost. The exceptions are the ones that embedded business logic in Workflow that never really belonged there, and those need a new home outside the SaaS boundary.

The hardest part of moving from EBS to Fusion, for the technical team, is not learning the new tools. It is accepting the new boundary. No direct DML on standard tables. No custom triggers on seeded objects. No PL/SQL running inside the application. No overnight batch that quietly rewrites a status column because someone once decided it was easier than fixing the process.

Every one of those patterns is expressible in Fusion, but through different mechanisms: business events triggering downstream processing, integrations moving data across the SaaS boundary, and extension applications that own their own database. The pattern is API first, and the discipline is separation. This shift is more consequential than any specific tool choice, and it is the shift teams underestimate most often.

One of the more useful outputs of a serious EBS to Fusion assessment is the list of customizations that simply do not need to be rebuilt. A meaningful share of any mature EBS estate consists of customizations that were built to fill a gap the standard product has since closed, or to support a process that has changed, or to work around a configuration that was never quite right in the first place. Those disappear on the way to Fusion, and the programme is genuinely better for it.

A separate meaningful share is customizations that still express a real business capability and must be rebuilt in Fusion's extensibility tooling. We are deliberately not quoting a percentage here, because the split depends entirely on the estate and any number we invented would be misleading. What we can say is that the ratio is discoverable, cheaply, through an audit, and it should be discovered before the implementation contract is signed, not after.

APEX is not a Fusion replacement and it is not a competitor to Fusion. It is a legitimate extension pattern that sits alongside Fusion for a specific and common class of problem: data heavy internal applications that need their own tables, their own reporting, and their own operational UI, while consuming Fusion as the system of record over REST. Recent APEX releases made this integration explicitly easier.

For an EBS technical team that already knows PL/SQL, APEX offers the additional benefit that the skills you already have keep earning their keep in a Fusion world. Rather than retraining the whole team on Visual Builder for every extension, the ones that are genuinely data heavy stay on a stack the team is productive in. This is the pattern we most often recommend, and it is the pattern most rarely proposed by implementation partners whose commercial model prefers Visual Builder for everything.

Every serious Fusion move begins with a customization inventory of the source EBS estate, correlated against actual usage over a representative period. Without it, the rebuild cost is a guess, the timeline is a guess, and the split between retire, rebuild and reconfigure is a guess. With it, the programme has a defensible baseline that the business can actually price.

Our Capabilities page describes the Oracle scope we cover and how we combine in-house EBS, OAF and APEX depth with a specialist network for Fusion and OCI. The one recommendation we make consistently, regardless of destination, is that the inventory work is done first, independently of whoever will implement the target platform. It is the cheapest piece of work in the programme and it is the one that most changes the shape of everything after it.