Migrating EBS to OCI

Migrating Oracle E Business Suite to Oracle Cloud Infrastructure is one of the most common Oracle workload moves, and also one of the most often underestimated. EBS is a large, multi tier, customized application that has usually been running for years, and the migration touches the database, the application tier, the integrations, and the operating model all at once. Treated as a simple server move it disappoints. Treated as a structured project with the right preparation, it goes smoothly and unlocks real benefits.

This article sets out a practical method for migrating EBS to OCI: how to assess the estate, which migration approach to choose, how to handle the cutover, and where the licensing decisions sit. It is the migration companion to our EBS on OCI architecture guide and part of the wider running Oracle applications on OCI series.

Start with a proper assessment

Every successful EBS migration starts with an assessment that establishes the facts rather than relying on assumptions about the estate. The assessment captures the EBS version and patch level, the database version and size, the number and role of application tier nodes, the customizations and extensions, the integrations to other systems, and the real performance profile of the estate measured under representative load. This last point matters because the on premises hardware was almost certainly bought for peak and for years of growth, so sizing the OCI target from the hardware specification rather than from measured demand carries the over provisioning straight into the cloud.

The assessment also surfaces the customizations, which are the part of an EBS estate most likely to cause surprises during a migration. Knowing what has been customized, why, and whether it is still used lets you plan the migration around the real estate rather than a generic version of EBS. This is the single most valuable preparation step, and skipping it is the most common reason EBS migrations run over.

Choose the migration approach

There are three broad approaches to moving EBS to OCI, and the right one depends on the database size, the acceptable downtime, and the version you are starting from. The first is a backup and restore, which suits smaller estates that can tolerate a longer outage window. The second uses Data Guard to build a standby of the EBS database in OCI and then switches over, which keeps the downtime short and suits larger estates. The third combines a database move with an EBS version upgrade, which makes sense when the estate is on an older release that should be upgraded anyway.

The decision is driven mainly by how much downtime the business can accept and how large the database is. A large database with a tight downtime window points to the Data Guard approach, because the standby is kept current and the switchover is quick. A small database with a generous window can use a simpler backup and restore. We help teams make this choice during the assessment, because choosing the wrong approach is expensive to correct once the migration is underway.

Build the target environment first

Before any data moves, the OCI target environment should be built and ready. That means the landing zone, the network with its tiered private subnets, the database platform, the application tier compute, and the load balancer, all defined as infrastructure as code so the environment is reproducible. Building the target first means the migration becomes a data and application move into a known good environment rather than a build and migrate at the same time, which is far harder to get right.

Defining the environment as code also pays off immediately afterward, because the same code builds the non production environments, the disaster recovery environment, and any future rebuilds. EBS estates are notorious for being hand built and undocumented, and the migration is the natural moment to replace that fragility with a reproducible, version controlled definition of the whole estate.

Handle the application tier deliberately

The EBS application tier needs as much attention as the database during a migration. The application tier holds the customizations, the configuration, and the integrations, and it is the part of the estate that benefits most from being rethought for OCI. Rather than copying the on premises application servers as they are, the migration should rebuild the application tier on OCI compute defined as code, carrying across the customizations and configuration deliberately rather than cloning a server whole.

This rebuild is also where the application tier gains the ability to scale, which is one of the main advantages of EBS on OCI. The on premises application tier was sized for peak and ran at that size all year. On OCI it can be sized for typical demand and scaled up for known peaks such as a quarter end close, which both improves the experience at peak and reduces the cost the rest of the time.

Plan the cutover carefully

The cutover is the point at which production moves from on premises to OCI, and it is where careful planning pays off most. A good cutover plan specifies the sequence of steps, the validation checks at each step, the point of no return, and the rollback plan if something goes wrong before that point. For a Data Guard based migration the cutover is a controlled switchover that takes minutes; for a backup and restore it is a longer outage during which the database is moved and the application tier brought up against it.

The cutover should be rehearsed at least once in a non production environment so the steps and timings are known rather than discovered on the night. The rehearsal also validates that the application works correctly on OCI, that the integrations connect, and that performance is acceptable, all before the production cutover commits the business to the new environment.

Validate before and after go live

Validation is what turns a technically complete migration into a trusted one. Before go live, the migrated environment should be validated against a checklist that covers the database, the application functions, the customizations, the integrations, the batch and concurrent processing, and the performance under representative load. After go live, the estate should be monitored closely for a period to catch any issues that only appear under real production load and real user behavior.

This validation is where the assessment pays off again, because the inventory of customizations and integrations from the assessment becomes the checklist for validation. An estate that was assessed thoroughly can be validated thoroughly; an estate that was not assessed properly tends to reveal its surprises during or after go live, which is the worst time to find them.

The licensing decision runs through everything

An EBS migration to OCI involves licensing decisions that interact closely with the architecture, and these are among the most consequential decisions in the whole project. The database platform choice, the way existing Oracle licenses transfer to OCI, and the use of a bring your own license model all affect the total cost substantially, and an architecture chosen without understanding the licensing implications can be costly to correct later.

Because the rules are intricate and the financial stakes are high, this is an area where independent expertise, free of any incentive to sell more capacity or more licenses, pays for itself many times over. We work alongside independent licensing specialists so the EBS architecture and the licensing model are decided together, which is the only way to avoid expensive surprises. For the architectural side that the licensing decision interacts with, see our EBS on OCI architecture guide.

Common migration mistakes

The most frequent EBS migration mistakes are predictable and avoidable. The first is skipping or rushing the assessment, which leaves the migration to discover the estate as it goes. The second is a straight lift and shift that copies the on premises layout without adopting OCI services, scaling, or infrastructure as code, which captures little of the benefit. The third is treating the cutover as a single untested event rather than a rehearsed procedure with a rollback plan. The fourth is leaving the licensing decision until after the architecture is fixed, which forecloses the cheaper options.

Avoiding these four is most of what separates a smooth EBS migration from a painful one. Each is a matter of preparation and discipline rather than technical difficulty, which is why a structured method matters more than raw technical skill on a migration like this. Our upgrading EBS on OCI guide covers the related question of combining a migration with a version upgrade.

After the migration

The migration is the start of the OCI estate rather than the end of the project. Once EBS is running on OCI, the estate needs a sound operating model covering patching, backup, monitoring, disaster recovery, and cost management. The disaster recovery side in particular deserves early attention, because the migration is the natural moment to build a regional standby that the on premises estate rarely had. Our guide to EBS disaster recovery on OCI covers that in detail.

Cost management also matters after go live, because the elastic application tier only delivers savings if it is actually sized to demand rather than left at peak. The migration gets the estate onto OCI; the operating model is what keeps it healthy, resilient, and economical over the years that follow. Our EBS on OCI workload service covers both the migration and the run.

Sequencing the environments

A clean EBS migration moves through a sequence of environments rather than jumping straight at production. A development or test environment is built first on OCI and used to prove the migration method, exercise the customizations, and confirm the integrations connect. A pre production environment that mirrors production follows, and it is used for the full rehearsal and for user acceptance testing. Only when those environments have validated the method does production move. Because each environment is built from the same infrastructure as code definition, they are faithful copies of one another, so a method that works in test genuinely works in production.

Sequencing this way spreads the risk and surfaces problems early, when they are cheap to fix, rather than late, when they threaten the go live date. It also gives the business a series of opportunities to see the application running on OCI before the production cutover, which builds confidence and reduces the surprises that erode trust in a migration. The environments are discarded or repurposed once their job is done, so the cost of this thoroughness is modest on OCI.

Managing the integrations

EBS rarely lives in isolation, and the integrations to other systems are among the most common sources of migration trouble. The assessment should inventory every integration, what it connects to, how it is triggered, and how sensitive it is to latency and addressing. During the migration, these integrations have to be reconnected in the OCI environment and validated, because an integration that worked against the on premises addresses may need reconfiguring for the new network. Integrations that cross back to systems remaining on premises also depend on the connectivity between OCI and the data center, which must be sized and made resilient.

Validating the integrations is part of the cutover rehearsal rather than an afterthought, because a broken integration discovered after go live can disrupt business processes that depend on EBS exchanging data with other systems. Treating the integrations as first class throughout the migration, from assessment through rehearsal to post go live monitoring, is what keeps the wider business processes working when EBS moves.

Right sizing during the move

The migration is the natural moment to right size the EBS estate, because the OCI target is built fresh and can be sized to measured demand rather than inherited from the on premises hardware. The on premises footprint was almost certainly bought for peak and for years of growth, so a faithful copy of it on OCI would carry that over provisioning across and waste money from day one. Sizing the database tier to the measured performance profile and the application tier to real concurrent and batch demand, with the ability to scale for known peaks, captures one of the main savings an EBS move offers.

This right sizing should be deliberate and evidence based rather than a guess, which is why the assessment measures real demand rather than reading the hardware specification. Getting the sizing right at migration time avoids both the waste of over provisioning and the risk of under provisioning, and it sets the estate up to be economical from the moment it goes live rather than something to be optimized later.