Oracle EBS modernization in 2026: the complete decision guide

Oracle EBS modernization is usually presented as one decision. It is not. It is four decisions that have been quietly bundled together, and most of the bad outcomes we see start with that conflation. A team is asked whether it should modernize Oracle E-Business Suite, and by the end of the first workshop the conversation has slid into replatforming on OCI, re-implementing on Fusion Cloud, retiring OAF pages, and upgrading from 12.1 to 12.2, as if they were the same programme. They are not. Each of those is a separate question with its own driver, its own risk profile and its own reversible or irreversible cost. This guide separates them and walks through how to sequence the answer.

We write this from the position of a boutique Oracle team that does the work itself. We run EBS environments, we rebuild OAF and Oracle Forms customizations on Oracle APEX, we deliver Fusion Cloud and OCI alongside vetted specialists, and we spend most of our time with heads of applications who are trying to make an honest call under real budget pressure. The intent of this guide is not to sell any particular path. It is to make the four paths legible so that the decision, whichever way it goes, is deliberate.

Everything downstream of this discussion depends on which EBS release you are running today. The hard split is between EBS 12.1 and EBS 12.2, and it is not a technical detail. It is the difference between a supported, actively maintained enterprise application and one that is not.

EBS 12.2 is in Premier Support through at least 2037. On 25 March 2026, Oracle extended Premier Support for 12.2 by another year, the ninth consecutive annual extension since the Continuous Innovation model began in June 2018. The latest release update pack, 12.2.15, shipped in October 2025. In practical terms, if you are on 12.2 you are on a fully supported platform that continues to receive new functionality, quarterly Critical Patch Updates, tax and regulatory updates and third party certifications. You have time to make careful decisions.

EBS 12.1 is a different conversation. It is in Sustaining Support. That means no new updates, no new security fixes, no new tax and regulatory updates and no new third party certifications. It does not mean it will stop running tomorrow, but the compliance and vendor certification runway is finite and shortening every quarter. If you are on 12.1, the question in front of you is a support and risk question first, and a modernization question second.

We cover this split in more depth in the article on the 2037 extension, which explains what Premier Support really covers, and in the 12.1 upgrade decision article, which explains why staying on 12.1 is not a stable long term posture. Before you evaluate any of the four paths below, be clear which release you are on and be clear whether that release is in Premier or Sustaining Support. Every downstream cost estimate is anchored to that answer.

The first path is the one that gets the least attention because no one is trying to sell it to you. If you are on EBS 12.2, the vendor has publicly committed to supporting the platform through at least 2037, and your regulatory reporting is met by current release update packs, then the honest baseline is to stay on 12.2 and spend your modernization budget on the parts of the estate that actually hurt.

In most 12.2 estates, the pain is not the core ERP. It is the surrounding customization layer. Oracle Application Framework pages that were written a decade ago, Oracle Forms screens that only two people in the company still know how to change, custom PL/SQL packages whose behaviour is not fully documented, RICE objects that were built for a business process that no longer exists in that shape. These are the parts of the estate that raise the cost of every change, that block upgrades, and that make new hires slow to become productive.

Modernizing customizations on a supported 12.2 platform typically means an incremental rebuild of OAF and Forms into Oracle APEX, running side by side with the existing screens, retiring the old ones a page at a time. Our OAF to APEX rebuild walkthrough describes what that looks like in practice, and the article on the OAF and Forms skills cliff explains why the market for people who can maintain those two technologies is contracting faster than the code is being retired.

This path suits organizations whose ERP configuration is a reasonable fit for their business, whose 12.2 environment is stable, and whose main friction is the custom layer. What it costs is proportional to the size and importance of that layer. What it does not solve is a genuinely bad ERP fit. If your finance, HR or supply chain processes are fundamentally at odds with what EBS was designed to support, no amount of customization rebuild will change that, and one of the other three paths becomes the honest answer.

If you are on EBS 12.1, this is not really an optional path. Sustaining Support is a holding pattern, not a destination. The question is not whether to move off 12.1, but how much effort the move will take and what you should choose to change at the same time. Both answers are dominated by the customization estate.

EBS 12.2 introduced Online Patching and edition-based redefinition. That is the technical mechanism that lets Oracle apply patches to a running EBS environment with dramatically reduced downtime. It is a real operational win, and it is also the single largest source of upgrade effort. Every piece of custom code that lives in the EBS schemas has to be edition-compliant to work with online patching. In most 12.1 estates that have been running for a decade or more, a meaningful percentage of the custom PL/SQL, custom triggers and custom objects were not written with editions in mind, because editions did not exist when they were written. That code has to be reviewed and, in many cases, remediated.

The other place effort goes is the test cycle. A serious 12.1 to 12.2 upgrade is not a single cutover. It is a sequence of practice upgrades in lower environments, each of which flushes out a fresh set of regressions in customizations, interfaces and reports. The upgrade itself, in Oracle's own tooling, is well documented. What is not well documented is your custom estate, and that is where the surprise cost lives.

The 12.1 upgrade decision article covers the analysis in more depth, including the trap of trying to combine the upgrade with too many other changes at the same time. For the purposes of this guide, the important point is that a 12.1 to 12.2 upgrade is worth costing seriously and separately, and that its cost is a function of the customization inventory, not the standard product.

The third path is a change of infrastructure, not a change of application. Replatforming EBS onto Oracle Cloud Infrastructure means the same EBS you are running today, on the same release, with the same customizations, running on OCI compute and storage instead of on the tin in your data centre. Oracle provides EBS Cloud Manager to automate provisioning and lifecycle operations for EBS on OCI, and existing licences can be reused under Bring Your Own License so that the move does not force a licensing renegotiation.

What actually changes on this path is the operating model. You stop owning the hardware refresh cycle, network kit, data centre power and cooling, and the manual work of provisioning environments. Cloning production down to a fresh test instance becomes an automated operation instead of a two week ticket. Disaster recovery becomes a configuration exercise instead of a capital project. Patching cadence improves because the pain of standing up environments to patch against drops.

What does not change is the application. Your customizations run the same way they did before, your integrations behave the same way, your reports look the same and your users log in to the same screens. Replatforming does not, by itself, retire OAF, rebuild Forms, remove technical debt or improve ERP fit. It is easy to conflate those benefits into the OCI business case, especially when a cloud pitch is running alongside, and that conflation is one of the most common causes of disappointment eighteen months later.

The article on what changes when EBS moves to OCI covers the operational shift in detail, including the parts, such as licensing, that we intentionally decline to price and instead defer to Oracle or a licensing specialist. Our position on licensing is unchanged in this guide: it is the customer's contractual conversation, not ours. On the engineering side, OCI is a mature, well documented target for EBS, and the replatform itself is a well trodden path when the scope is kept honest.

The fourth path is the largest. Moving from EBS to Oracle Fusion Cloud Applications is a re-implementation, not an upgrade. Fusion is a different product line built on a different data model with a different extensibility approach. The core ERP capabilities are real, they are actively invested in, and Release 26B in 2026 introduced 22 Fusion Agentic Applications across ERP, HCM, SCM and CX, which is a substantive step in how the suite integrates AI into day to day process flow.

The important honest statement is that EBS customizations do not carry across. OAF personalizations, Oracle Forms screens, custom PL/SQL packages, RICE objects and Workflow customizations have to be rebuilt using Fusion's own extensibility tooling, which is a different toolset with a different mental model. Reports built on the EBS data model have to be rebuilt against the Fusion data model. Integrations have to be reworked against Fusion's APIs. Data migration is a serious programme in itself, especially where historical transactional data has to be reconciled.

This is a multi-year commitment for any organization at reasonable scale, and it is best approached as a business transformation programme with an ERP replacement inside it, not as an IT upgrade. Where the fit is right, Fusion delivers capabilities that EBS does not, particularly in the newer Fusion-only areas and in the agentic workflows introduced in 26B. Where the fit is wrong, either because the process design is genuinely non-standard or because the appetite for that scale of change is not there, forcing a Fusion re-implementation onto an unwilling estate is the fastest way to burn multi-million-dollar budgets and stall.

The article on Fusion 26B agentic applications explores what the new capabilities actually do and where they are strongest, so that a Fusion business case can be assessed on real capability rather than headline claims. What matters for this guide is that Path 4 is a genuine option, not a foregone conclusion, and it belongs on the shortlist only where the business is prepared to run it as a transformation.

The four paths, plus the honest null option of doing nothing, are best compared in one place. The table below is deliberately compact, because the differences that matter are structural, not marginal.

The right path is a function of a small number of questions. In our experience these are the ones that actually determine the answer, and asking them in this order avoids the common trap of picking an architecture first and then justifying it.

1. Which EBS release are you running today, and is it in Premier or Sustaining Support? If it is 12.1, the upgrade question is not optional and every other question is downstream of that.
2. How much of your customization estate is still actively used? An inventory that separates in-use from technically-present code often changes the size of every path.
3. Is a hardware refresh, data centre exit or major infrastructure change imminent in the next 18 to 24 months? If yes, the OCI conversation belongs in the plan whether or not it becomes the answer.
4. Are your business processes genuinely non-standard, or are they historically non-standard because of decisions made years ago that no one has revisited? These look identical on paper and require very different responses.
5. How deep is your internal Oracle bench, and how much of the change can it own end to end without becoming dependent on a single vendor?
6. What are your regulatory reporting and data residency obligations, and do they constrain region choice, hosting model or audit posture?
7. What is your organization's realistic appetite for a multi-year transformation programme in the next 24 to 36 months, and is executive sponsorship durable enough to survive it?

None of these questions has a single right answer. What they do is expose which of the four paths is actually consistent with the organization you are, rather than the organization a slide deck assumes you are.

Whichever path you choose, including the null option, you are better off knowing exactly what custom code you own and which of it is still used. This is the single most useful piece of work an EBS estate can commission before deciding anything else, and it is the one that gets skipped most often, usually because it is unglamorous and does not have a vendor selling it.

A serious customization audit inventories every OAF personalization, every Forms screen, every custom PL/SQL package, every RICE object and every Workflow customization. It then correlates each item against actual usage data over a representative period, so that the difference between technically-present code and in-use code becomes visible. In our experience, the volume of custom code that has not been touched or triggered in years is consistently underestimated by the people closest to the estate, because familiarity is not the same as evidence.

This is one of the practical outcomes we deliver inside an EBS Care retainer, alongside ongoing senior support and quarterly Critical Patch Update work. The article on what an EBS technical care retainer actually covers describes the shape of the work in more detail. The reason we mention it here is that the audit output is the same input every modernization path needs. It is the least regrettable piece of work in the entire programme.

A small number of mistakes account for most of the disappointing outcomes in Oracle EBS modernization programmes. They are worth naming plainly so they can be checked against in your own planning.

• Treating a support date as a deadline. Support dates are risk boundaries, not project milestones. When a support date becomes a deadline, decisions collapse toward whatever the loudest vendor is offering.
• Letting a vendor's product line decide the architecture. The right target state for your estate is not necessarily the target state that maps most cleanly onto the vendor's roadmap slide.
• Combining too many changes into one cutover. A programme that upgrades EBS, replatforms onto OCI and retires half the custom layer in one weekend is a programme that will find every latent defect at once, without a way to isolate them.
• Sizing an upgrade before inventorying customizations. Standard upgrade guides describe the standard product. The cost you will actually incur is dominated by the non-standard part of your estate.
• Assuming a replatform removes technical debt. OCI is a real operational win. It is not, by itself, application modernization, and expecting it to be one is the fastest route to a disappointed board eighteen months later.

Sequencing matters as much as the destination. In most estates we work with, a realistic ordering looks like this.

1. Assessment first. A customization audit, a support posture check and a plain read of the ERP fit against current processes. This work is cheap relative to the decisions it informs, and it is reusable across every subsequent path.
2. The cheapest reversible change next. If you are on 12.1, that is planning the 12.2 upgrade. If you are on 12.2, that is starting to retire the highest-friction customizations incrementally, page by page, in a way that can be paused without loss.
3. The structural change last, deliberately. Whether that is an OCI replatform or a Fusion re-implementation, it is undertaken with a clean customization inventory in hand, with the reversible improvements already banked, and with a business sponsor who understands the scale of what they are agreeing to.

This ordering resists the temptation to make the biggest, most exciting decision first. In our experience, the biggest decisions made first are the ones most likely to be revisited in year two.

This guide is deliberately a hub. Each of the paths above is explored in more depth in a dedicated article, and every one of them is worth reading before committing to a direction.

• EBS 12.2 Premier Support extended to 2037: what it means for your customizations. Read at /insights/ebs-12-2-premier-support-2037-what-it-means.
• The OAF and Forms skills cliff in 2026. Read at /insights/oaf-forms-skills-cliff-2026.
• OAF to APEX: a rebuild walkthrough. Read at /insights/oaf-to-apex-rebuild-walkthrough.
• The EBS 12.1 upgrade decision. Read at /insights/ebs-12-1-upgrade-decision.
• EBS on OCI: what changes and what does not. Read at /insights/ebs-on-oci-what-changes.
• Fusion 26B agentic applications: what it means. Read at /insights/fusion-26b-agentic-applications-what-it-means.
• What an EBS technical care retainer actually covers. Read at /insights/what-ebs-technical-care-retainer-covers.

We are a boutique Oracle team with in-house depth in EBS, OAF and APEX. Fusion Cloud and OCI work is delivered alongside a small network of vetted specialists we have worked with for years, so that we can size an engagement to what the estate actually needs rather than to what a large integrator would prefer to sell. Our EBS Care retainer covers ongoing senior support, customization audits and the incremental modernization work described in Path 1, and our Capabilities page sets out the wider Oracle scope we cover.

The first step in any modernization conversation with us is an assessment, not a proposal. If it turns out the honest answer is to do less than you thought, we would rather tell you that than build a bigger programme than you need. That is the version of this work we think holds up over the ten year horizon that EBS 12.2 now clearly has.