A national retailer ran its business on Oracle E Business Suite hosted in an ageing data centre, and a looming hardware refresh forced a decision: spend heavily to renew on premises, or move to the cloud. The board wanted the move done before the peak trading season, which left a ninety day window. Ninety days to migrate a business critical ERP sounds reckless, and done badly it would be. This case explains how a disciplined phased plan made that timeline realistic and delivered a clean cutover on schedule.
It is part of our OCI case studies and benchmarks cluster, and it pairs the migration timeline thinking of our timeline benchmarks with a real engagement. The client is anonymised by sector in line with how we present every case.
The situation
The retailer's E Business Suite estate carried finance, procurement, and supply chain for several hundred stores, and any extended outage would stop goods reaching shelves. The on premises hardware was at end of life, the maintenance costs were rising, and the team that knew the system was small. The deadline was not arbitrary: a code freeze ahead of peak trading meant the migration had to complete, stabilise, and be proven well before the busiest weeks of the year.
The constraints were therefore severe. A fixed and short timeline, a system that could not be allowed to fail, and a small team. Those constraints shaped the entire approach, because a migration under that kind of pressure cannot afford rework, surprises, or a big bang cutover with no way back. Every choice had to reduce risk and protect the deadline at once.
What we did
The work was structured into clear phases so that progress was visible and risk was contained. The first phase was discovery and design, mapping the existing estate, sizing the target, and designing the OCI landing zone before any workload moved. The second phase built that landing zone as infrastructure as code, so the target environment was repeatable and could be rebuilt or scaled without manual effort.
The third phase was iterative migration of non production environments first, development then test then a staging copy of production, each one rehearsing the cutover and surfacing issues while the stakes were low. By the time the production cutover came, the move had been practised several times, the runbook was proven, and the timings were known. The final phase was the production cutover itself, executed inside a planned window with a tested rollback path that was never needed.
The OCI architecture used
The target was a landing zone built to a secure, segmented design, with the E Business Suite application tiers on OCI compute shapes sized from the measured load of the old estate, and the database on a configuration that matched the performance the business needed. The environments were separated into their own compartments, network access was controlled tightly, and everything was defined in code so that test and production were faithful copies of one another.
Backup, monitoring, and the failover design were built in from the start rather than added afterwards, so that the estate arrived in production already operable. This mirrors the architecture we describe in our EBS on OCI workload guide, where the application and database tiers are sized from evidence and the supporting services are part of the build rather than an afterthought.
| Phase | Weeks | What it delivered |
|---|---|---|
| Discovery and design | 1 to 3 | Estate map, target sizing, landing zone design |
| Landing zone build | 3 to 5 | Secure target environment as code |
| Non production migration | 5 to 10 | Dev, test, staging moved and rehearsed |
| Production cutover | 11 to 12 | Planned window, tested rollback, go live |
| Stabilise | 12 to 13 | Hypercare, tuning, handover to run |
The measurable result
The migration completed inside the ninety day window, with the production cutover landing in its planned window and the business operating normally the next morning. Infrastructure cost fell compared with the renewed on premises option the retailer had been quoted, because the OCI estate was sized to actual load rather than to a hardware refresh cycle, and capacity could be adjusted rather than bought in large fixed blocks.
Performance held or improved, the peak trading season ran on the new estate without incident, and the small team gained a platform they could operate with far less manual effort. The result was the rare combination a board hopes for: a hard deadline met, cost reduced, and risk controlled throughout. The cost reduction sits alongside the patterns in our manufacturer cost case, and the timeline matched the ranges in our 2026 migration benchmarks.
Why the timeline held
The ninety days held because nothing was left to chance at the end. The cutover that mattered had been rehearsed on staging, the rollback had been tested, and the runbook had been refined through several practice runs. The pressure of the deadline was absorbed early, in the phases where mistakes were cheap, rather than late, where a mistake would have been a peak season outage.
This is the lesson that runs through the case studies pillar: ambitious timelines are met not by working faster on the day but by rehearsing relentlessly beforehand. Designing and running that kind of disciplined migration is exactly what our OCI implementation and migration service exists to do.
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.