What It Costs to Migrate EBS to OCI: Line by Line

Oracle E Business Suite is usually the most consequential workload in any OCI migration program. It touches finance, supply chain, HR, and procurement, it carries years of customizations and integrations, and the business cannot tolerate it being wrong for even a day. That weight is exactly why EBS migration estimates so often go sideways. Vendors quote the visible lines, the compute and the cutover weekend, and leave the expensive ones, the testing cycles and the dual running period, as someone else's problem to discover later. A complete budget has roughly a dozen lines, and every one of them is knowable in advance if you do the work.

This article is part of our series on what an OCI migration really costs, which covers the full assessment and budgeting method across any workload. Here we apply it specifically to E Business Suite, line by line, in the order the money is actually spent.

Line one: assessment and discovery

Every credible EBS budget starts with a paid discovery exercise, typically two to four weeks, that inventories the estate: EBS version and patch level, database version and size, the customization count by complexity, the integration map, the concurrent processing profile, and the batch windows the business actually depends on. This line is usually 3 to 5 percent of the total project, and it is the cheapest money in the entire program because every downstream line is priced from what discovery finds. An estimate produced without discovery is not an estimate, it is a placeholder that will be corrected later at a much worse rate. We run this phase on a fixed project fee precisely so the output is a number the CFO can hold someone to.

Line two: target architecture choices

The next decision sets the shape of everything that follows. For most organizations the realistic options are a lift and shift of the existing EBS release onto OCI compute, or a replatform that combines the move with an upgrade to EBS 12.2 and a current database release. Lift and shift is cheaper on the project side, often 30 to 40 percent cheaper in execution effort, but it carries technical debt into the cloud with you. Replatforming costs more up front and adds testing scope, but it resets the support clock and avoids paying for a second project eighteen months later.

Oracle EBS Cloud Manager changes the economics of either path. It automates provisioning, cloning, and lifecycle operations for EBS environments on OCI, which means the cost of standing up an additional test environment drops from weeks of consultant time to hours of automation. Budgeting for Cloud Manager setup early, usually a modest line inside the landing zone work, pays itself back several times over during the testing phase.

Line three: the landing zone share

EBS never arrives on OCI alone. It lands inside a landing zone: the compartment design, identity integration, network segmentation, security policies, logging, and tagging standards that every workload will share. The full landing zone build is typically 10 to 15 percent of a first migration program, but EBS should only carry its fair share of that cost, because the foundation serves everything that follows it. If an EBS quote includes the entire landing zone, you are paying for infrastructure that the next three workloads will use for free. Our OCI implementation practice builds the landing zone as a separately priced, fixed fee deliverable for exactly this reason: it keeps the EBS line honest and makes the second workload visibly cheaper.

Line four: environment count

This is the first line where budgets quietly double. An EBS estate is never one environment. A typical program needs production, a full test environment for business validation, a development environment for the technical team, and a disaster recovery target, and many enterprises add a patch testing or training instance on top. Each environment carries compute, storage, and database cost for as long as it runs. The discipline that controls this line is lifecycle management: nonproduction environments built on demand through Cloud Manager, scaled down or stopped outside working hours, and decommissioned the moment a testing phase ends. An always on test estate sized like production is the single most common piece of waste we remove in optimization reviews.

Lines five through eight: the infrastructure build

Database tier sizing

The EBS database tier is the largest infrastructure line, and the biggest sizing mistake is copying the on premises specification into the cloud. On premises hardware was sized for a peak that may occur four nights a month, plus headroom bought years ago. OCI lets you size to the measured workload from your AWR history and scale for period close. Whether the target is Base Database Service, Exadata, or compute hosted, sizing from evidence rather than from the old hardware order typically cuts this line by a third before the migration even starts. The database tier deserves its own analysis, and we cover the method in detail in what database migration to OCI costs.

Application tier

The application and concurrent processing tiers are more forgiving. They scale horizontally, so the budget question is the number and shape of the application nodes, whether the concurrent managers get dedicated capacity, and how much of the estate can run on flexible shapes that scale with demand. This line is usually half or less of the database tier, and it is the easiest to adjust after go live once real usage data exists.

Storage

Storage for an EBS estate covers the database files, the shared application file system, backups, and clones. The line itself is modest, but it grows silently: every clone of production for testing duplicates the full database footprint unless the cloning strategy uses snapshots and thin provisioning. Set the clone policy in the architecture phase, not after the third full copy appears on the bill.

Networking and FastConnect

EBS users feel latency in every form and every report, so most enterprises put FastConnect, a dedicated private circuit into OCI, in the budget from day one. The line includes the port cost, the carrier circuit, and the engineering to set it up with proper redundancy, and during migration it also carries the bulk data transfer. It is a small percentage of the total, but it is on the critical path: a FastConnect circuit can take weeks to provision, so the spend must be committed early even though the benefit lands late.

Line nine: migration execution effort

Execution effort is where estate complexity shows up in the price. A vanilla EBS 12.2 instance with few customizations and a database under 5 TB is a known quantity: the move itself is weeks of work. Add hundreds of customizations, a 30 TB database, dozens of interfaces to warehouse systems, banks, and tax engines, and the effort multiplies, not because the EBS move changed but because every customization and integration must be remediated, repointed, and proven. Discovery exists to count these things before pricing, which is why a fixed project fee is only credible after discovery, and why an estimate offered before it should be treated as marketing. The same complexity curve applies to other Oracle applications, and readers comparing programs should see our companion piece on what a PeopleSoft migration to OCI costs.

Line ten: testing cycles, the largest hidden line

Here is the line that most often gets underbudgeted, and it is frequently the largest single line in the entire program. An EBS migration needs multiple full testing cycles: a technical validation pass, at least two rounds of business user acceptance testing across finance, supply chain, and HR processes, a performance test against the period close workload, and a full cutover rehearsal with timed rollback. Each cycle consumes consultant hours, business user time that finance teams must give up during their own busy calendar, and a freshly cloned environment. Programs that budget one testing cycle and need three do not overrun by a little, they overrun by months. Across 500+ engagements, the pattern is consistent: the quality of the testing budget predicts the quality of the go live better than any other line.

Line eleven: dual running

From the moment the OCI production environment is built until the old estate is switched off, you are paying for both. For an EBS program this dual running window is rarely shorter than two months and often stretches to six when testing slips or the business demands a fallback period after go live. The line is simple to model, the full monthly cost of the old estate multiplied by the number of overlap months, and brutal when ignored. Every week the schedule slips is a week of double payment, which is also why downtime planning and cutover discipline have a direct cash value, a subject we treat fully in what migration downtime really costs.

Line twelve: hypercare

The first four to six weeks after go live need intensive support: the migration team on call, daily checkpoints with the business, rapid fixes for the integration and performance issues that only production traffic reveals, and 24/7/365 monitoring of the new estate from day one. Hypercare is typically 5 to 10 percent of the project and it is the worst possible place to economize, because an issue caught in week one costs hours and the same issue found during month end close costs a war room. Many clients roll hypercare directly into a managed monthly retainer, so the team that moved the estate becomes the team that runs it, with no knowledge handover and no gap in coverage.

Line thirteen: the post go live optimization pass

The budget should end with a line most plans omit entirely: a structured optimization pass 60 to 90 days after go live. By then real usage data exists, and the conservative sizing decisions made under migration pressure can be corrected with evidence. Application nodes get right sized, test environments move to schedules, storage policies tighten, and the Universal Credits commitment gets renegotiated against actual consumption. Across our engagements this pass averages a 40% reduction in run rate spend, and we price it as an optimization fee paid only on verified savings, so the line costs nothing unless it works. Teams with 20+ years combined of running Oracle estates will tell you the same thing: nobody sizes perfectly before go live, so plan the correction instead of pretending it will not be needed.

The full picture in one table

A framework for building the EBS migration budget

Bringing it together

An EBS migration to OCI is not cheap, but it is honest work with knowable costs, and the gap between a smooth program and a painful one is almost never the technology. It is whether the budget had thirteen lines or four. Discovery, architecture, landing zone, environments, the infrastructure tiers, execution, testing, dual running, hypercare, and the optimization pass: price them all before you start and the project becomes a managed exercise. Skip the unglamorous ones and they will price themselves, at the worst possible moment, on the worst possible terms. If you want a budget built this way, with every line visible and a delivery model to match, whether fixed fee, monthly retainer, or savings based, start with an assessment and make the first number the right one.