Oracle E Business Suite is one of the most common workloads to move to OCI, and one of the most particular. This step by step walkthrough covers the order of operations that keeps an EBS migration on track.
Oracle E Business Suite migrations have a reputation for complexity, and it is earned. EBS is not one workload, it is a tightly bound stack of a database tier, an application tier, and a web of customisations, integrations and batch processing that has usually accreted over many years. Moving it to OCI rewards a methodical, staged approach far more than most workloads. This article lays out the steps in the order that works.
It sits within our pillar guide, The Complete Guide to Oracle Cloud Migration in 2026, and applies the general migration method to the specifics of EBS.
Before anything moves, document the entire EBS footprint. That means the EBS version and patch level, the database version and size, every customisation, every integration to surrounding systems, the concurrent processing setup, and the printing and reporting configuration. EBS customisations are the part that surprises teams most often, because they live in many layers and a missed one breaks the application in ways that only surface during user testing. This inventory feeds the broader assessment described in the pre migration checklist.
An EBS migration is a natural moment to decide whether you are also upgrading. Moving on the current version is faster and lower risk. Combining the move with an EBS or database upgrade captures two changes in one outage but raises complexity and testing effort. There is no universally right answer, only the one that fits your appetite for change and your timeline. Decide deliberately, because the choice cascades through every later step.
EBS lands on a landing zone like any other workload, but its tiers have particular networking and security needs. The database tier, the application tier and the access points each sit in appropriate network segments, with the security rules that EBS requires between them. Get the network topology right before the tiers arrive, because retrofitting it around a live EBS instance is painful.
The EBS database is migrated using the same methods as any Oracle database, chosen by size and downtime tolerance, and compared in Oracle Database Migration to OCI: Methods Compared. For a large EBS database that cannot take a long outage, the online methods in OCI Migration Tools: Zero Downtime Options apply. The EBS specific wrinkle is that the database and application tiers must stay version compatible, so the database method has to respect the EBS certification matrix.
The application tier carries the EBS code, the customisations, and the configuration. Oracle provides tooling to help move and reconfigure an EBS application tier for a new environment, and the work is largely about pointing the tier at the migrated database, reapplying environment specific configuration, and confirming every customisation came across. This is where the inventory from step one pays back, because each documented customisation becomes a checklist item to verify.
EBS rarely lives alone. It exchanges data with surrounding systems, runs concurrent programs on a schedule, and feeds reporting and printing. Every one of these connections has to be re established and tested against the OCI instance. Integrations that pointed at the old environment need their endpoints updated, and concurrent processing has to be confirmed working end to end. Missing one of these is a common cause of a go live that technically succeeded but left the business unable to run a critical process.
EBS validation goes well beyond confirming the application starts. It means functional testing of the modules the business actually uses, confirming batch jobs complete, checking that reports render and print, and comparing performance against the baseline captured before the move. The full validation discipline is in Post Migration Validation on OCI, and for EBS it should include business users exercising real transactions, not just a technical smoke test.
| Step | Tier | Key risk if skipped |
|---|---|---|
| Inventory | All | Missed customisation breaks the app later |
| Database migration | Database | Version mismatch with application tier |
| Application migration | Application | Configuration and code gaps |
| Integrations and batch | Surrounding | Business process cannot run after go live |
| Validation | All | Defects reach users in production |
The cutover sequence for EBS brings the migrated database and application tiers into service together, redirects users, and confirms the stack before releasing the old environment. As with every migration, a tested rollback path is defined before cutover, following the approach in Rollback Strategy for OCI Migrations. Because EBS touches so many business processes, the stabilisation window after go live should be generous, with extra support on hand for the first full processing cycle.
EBS migrations reward teams who have done them before and know where the customisation and integration traps hide. Our OCI Implementation and Migration practice runs EBS moves end to end, tier by tier, with the validation depth the workload demands. An assessment will tell you how complex your particular EBS estate is and what the move involves.
The reason EBS migrations benefit so much from a staged, ordered approach is that the stack is interdependent in ways that punish shortcuts. The application tier must match the database tier on version. The customisations must come across intact or the application misbehaves in subtle ways. The integrations and concurrent processing must reconnect or business processes silently fail. A staged approach, where each tier is migrated and validated before the next is brought into play, isolates problems to the layer that caused them and keeps the whole move debuggable. Trying to move everything at once turns a complex but tractable migration into an unbounded one.
EBS customisations are the most common source of post migration surprises because they live in many places and accumulate over years. Custom forms, reports, workflows, database objects, and integrations all count, and the inventory of them from step one is the single most valuable artifact in the migration. Each customisation becomes a verification item, confirmed working against the OCI instance during validation. Teams that treat the customisation inventory casually are the teams whose users find the gaps in production. Treat it as a formal register, owned and checked.
EBS performance on OCI depends on sizing the database and application tiers to the real concurrent user load and the batch profile, not to the old hardware. The concurrent processing tier in particular needs enough capacity to clear its queues within the windows the business depends on, and that is a sizing question best answered from measured load on the source. After go live, compare response times and batch completion times against the pre move baseline, and right size where the measurements show headroom. The first processing cycle after cutover is the real test, so plan extra support around it.
Because an EBS migration already involves a full validation cycle, it can be tempting to combine it with an EBS or database upgrade and get two changes for one outage. This is reasonable, but it raises the testing burden and the risk, because now any defect could come from the move or the upgrade. If you combine them, expand the testing accordingly and keep the rollback path clear. If the timeline is tight or the appetite for risk is low, move first and upgrade later as a separate, lower stakes project. Either choice is defensible, but it should be made deliberately rather than by accident.
EBS touches so many business processes that the first days after cutover deserve heightened support. The first full processing cycle, the first batch run, the first period close, and the first round of reports are the real tests, and having extra hands available during them turns potential incidents into quick fixes. Plan the support model before go live, with clear escalation paths, the right people on call, and the customisation and integration registers close at hand so any gap can be traced quickly to its source. A generous stabilisation window is not over caution with EBS, it is prudence.
You can, and it captures two changes in one outage, but it raises testing effort and risk because a defect could come from either change. If the timeline is tight or risk appetite is low, migrate first and upgrade as a separate project later.
Customisations and integrations. A missed customisation or an integration still pointing at the old environment is the most common cause of a go live that technically succeeded but left a business process unable to run.
Choose a database migration method that respects the EBS certification matrix, and keep the tiers version aligned throughout. The tiers must match, so the database method has to honour that constraint.
Long enough to cover at least one full processing cycle, including any period close or batch heavy run, with extra support on hand throughout.
EBS rarely runs in isolation from a set of peripheral services that users depend on daily, and these are easy to overlook in the focus on the database and application tiers. Reporting, whether through built in tools or third party report writers, has to be reconnected and tested. Printing, which in many EBS environments routes through specific configuration, has to be confirmed end to end, because a finance team that cannot print cheques or invoices on go live day has a real problem regardless of how cleanly the core migrated. Document these peripheral services in the inventory and treat each as a verification item, because their absence from a test plan is a frequent cause of go live friction that had nothing to do with the main migration.
The concurrent processing tier is where EBS does much of its heavy lifting, running the batch programs that close periods, generate reports and move data. Sizing it correctly on OCI is essential, because a tier that cannot clear its queues within the business windows turns a technically successful migration into an operational failure. Size the tier from the measured concurrent processing load on the source, accounting for peak periods like month end rather than average days, and confirm during validation that the heaviest batch runs complete within their windows. Because OCI lets you adjust capacity after go live, you can refine the sizing once real load is observed, but starting from measured demand rather than guesswork avoids a painful first period close.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings. For the Oracle licensing and BYOL side of any OCI move, Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line.