Lift and shift gets you to OCI fast. Re platforming gets you more value once you arrive. Choosing between them per workload, rather than applying one approach to everything, is one of the biggest levers on a migration.
The first real argument in most OCI migrations is about how much to change on the way across. One camp wants to lift and shift everything, move fast, and modernise later. The other wants to re platform as it goes, on the logic that you are touching the workload anyway. Both are right, for different workloads. The mistake is treating it as a single policy decision rather than a per workload judgement. This article gives you the criteria to make that judgement well.
It sits under our pillar guide, The Complete Guide to Oracle Cloud Migration in 2026, which frames these two patterns alongside the other five Rs.
Lift and shift, also called rehosting, moves a workload to OCI with as little change as possible. The same operating system, the same application binaries, the same architecture, now running on OCI compute instead of on premises or another cloud. Re platforming moves the workload but swaps one or more components for a managed or cloud native equivalent along the way. The classic example is moving an application server as is while shifting its database from self managed to Base Database or Autonomous Database.
| Dimension | Lift and shift | Re platform |
|---|---|---|
| Speed to migrate | Fast | Slower |
| Migration risk | Lower, fewer changes | Higher, more changes to test |
| Day one cost | Often higher, like for like sizing | Often lower, managed services |
| Operational burden after | Unchanged, you still run everything | Reduced, the platform runs more |
| Long term value | Limited until later work | Captured immediately |
| Best for | Data centre exits on a deadline | Strategic workloads worth investing in |
Rehosting is the right call when speed is the dominant constraint. A data centre lease ending in ninety days does not care about architectural elegance, it cares about getting workloads out before the doors close. Rehosting also wins for stable, low change applications where the cost of re engineering would never pay back, and for systems nearing end of life where any investment is wasted. The discipline here is to rehost cleanly, capture a performance baseline, and schedule the optimisation pass for after go live rather than abandoning it entirely.
The risk of pure lift and shift is that day one cost can be higher than expected, because teams size OCI instances to match on premises hardware that was itself over provisioned. The fix is a deliberate right sizing pass once real utilisation data arrives on OCI, which is exactly the kind of quick win that the optimisation phase of a migration is built to capture.
Re platforming earns its extra effort when the workload is strategic, when the managed service genuinely reduces operational burden, and when you are already going to retest the application anyway. Moving a self managed Oracle Database to Autonomous Database, for instance, removes patching and tuning toil that recurs forever, so the one time cost of the change pays back continuously. The decision is fundamentally about payback period. If the operational savings recover the migration premium inside a reasonable window, re platform. If they do not, rehost and revisit later.
The most reliable pattern for large estates is to lift and shift first to hit the deadline, then re platform selectively once the workloads are stable on OCI. This separates the two risks. The migration risk is contained to the move itself, and the change risk of re platforming happens later, against a system you already understand on its new home. The phased approach is explored further in our wider migration content, and the wave structure that supports it is in How to Plan an OCI Migration Wave.
For the database component specifically, the method you use interacts with this choice, because some online migration methods make a platform change easy and others do not. That detail is in Oracle Database Migration to OCI: Methods Compared. And whichever path you choose, validate against the pre move baseline, as set out in Post Migration Validation on OCI.
The estates that migrate well are the ones that resist a single policy and instead classify each workload deliberately. Our OCI Implementation and Migration team builds that classification into the assessment, so the wave plan reflects a considered mix of rehost and re platform rather than a blanket choice made under deadline pressure. An assessment is the place to start that conversation.
Lift and shift is often sold as risk free, and at migration time it largely is. The cost it carries is deferred, not absent. A workload rehosted as is still carries whatever operational burden it had on premises, the same patching, the same tuning, the same manual recovery procedures, now running in a place where managed alternatives existed. If the optimisation and modernisation work never happens, the organisation pays that burden indefinitely while sitting on a platform that offered to take it away. The discipline that makes lift and shift sound is committing, in writing, to the follow up work, with an owner and a date, rather than letting later become never.
The opposite failure is real too. Teams enthusiastic about cloud native design sometimes re platform workloads that did not need it, turning a straightforward move into a software project with its own testing burden and its own chance of introducing defects. Re platforming is justified by payback, and a workload that is stable, low change and near end of life has little payback to offer. Applying the heaviest pattern to a workload that warranted the lightest is how a migration timeline doubles for no business return. Match the effort to the value.
The two approaches land at different points on the run cost curve. A pure lift and shift, sized like for like, often starts higher than it should because it imports over provisioning, and it only comes down if a right sizing pass follows. A re platform to managed services can start lower, because the managed service is sized to actual demand and removes some infrastructure you would otherwise run, but it carries the one time cost of the change. The cost modelling that compares these paths is set out in our migration cost guidance, and the comparison is worth doing per workload rather than assuming one is always cheaper.
For most estates facing a deadline, a sound default is to lift and shift to meet the date, capture a clean performance and cost baseline, and then run a deliberate optimisation and selective re platforming pass once workloads are stable. This sequences the risks so they never compound, and it lets the business realise the deadline benefit immediately while the value benefit follows in a controlled second phase. The waves that carry this are structured in our wave planning guidance, and the validation that gates each step protects the whole sequence.
Consider a typical mid sized estate facing a data centre exit in six months. It contains a core Oracle database supporting a critical application, a dozen stable internal applications, a handful of strategic customer facing services, and several systems nearing retirement. A blanket lift and shift would meet the deadline but leave value on the table. A blanket re platform would miss the deadline entirely. The sound plan rehosts the stable internal applications and the near end of life systems to hit the date, re platforms the core database to a managed service because the operational savings recur forever, and re platforms the strategic customer services because they will be invested in regardless. The retiring systems may not move at all. One estate, four patterns, each chosen on its merits.
No. It is faster and lower risk at migration time, but day one run cost can be higher because workloads are often sized to over provisioned hardware. It only becomes cheap after a right sizing pass, which is why that follow up work matters.
When a managed equivalent removes recurring operational toil and the savings recover the migration premium quickly. Moving a self managed database to a managed service is the classic case.
Yes, and for estates under deadline this is often the best sequence. It separates the migration risk from the change risk and lets the business capture the deadline benefit immediately while value follows in a controlled second phase.
Run each workload through four questions, is there a hard deadline, is it strategic, does a managed equivalent exist, and what is the payback period. The answers point clearly to rehost or re platform.
The choice between rehosting and re platforming reaches beyond the migration into how the estate is run afterward, and that downstream effect deserves weight in the decision. A rehosted workload keeps the same operational profile it had before, which means the team needs the same skills and carries the same responsibilities for patching, tuning and recovery. A re platformed workload shifts some of that responsibility to the platform, which changes what the operations team does day to day, often reducing toil but also requiring familiarity with the managed service. Neither is automatically better, but the operating model has to match the choice. An estate that re platforms heavily without building the skills to run managed services, or one that rehosts everything and then finds it lacks the people to run it all, has chosen a pattern its operating model cannot support.
A rehost decision made under deadline is not permanent. Workloads that lifted and shifted to meet a date can be re platformed later when the pressure is off and the business case is clearer, and a healthy estate revisits these choices periodically. A workload that was stable and low priority at migration may become strategic, justifying investment that did not make sense before. Treating the rehost versus re platform decision as a point in time judgement that can be revisited, rather than a permanent classification, keeps the estate aligned with the business as both evolve. The optimisation practice that runs after go live is the natural home for these reassessments.
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.