Lift-and-shift vs re-platform

Lift-and-shift, or rehosting, takes an application as it is, often a virtual machine image, and runs it on cloud infrastructure. Nothing in the code changes. It is fast and low-risk, and it captures some benefits such as leaving an ageing data centre, but the application still behaves like it did, with the same scaling limits and operational burden.

Re-platforming makes targeted changes to exploit the new platform without rewriting the application: moving a self-managed MySQL to a managed database, containerising a service, replacing a local file store with object storage, or swapping a cron job for a managed scheduler. It takes longer and needs testing, but it reduces operating cost and makes later modernization easier.

Neither is refactoring or rebuilding, which change the application's architecture. The common mistake is to lift-and-shift and declare the migration done; the bill often goes up, because cloud pricing punishes always-on, over-provisioned servers that were sized for a data centre.

• CFO: lift-and-shift is cheap upfront but can raise the monthly run cost; re-platforming costs more once and usually lowers it.
• CTO / Head of Engineering: re-platforming removes patching and backup toil and creates the seams needed for later modernization.
• CISO: managed databases and identity services bring patching, encryption and audit features that a lifted VM lacks.
• Operations head: lift-and-shift can be done with minimal disruption; re-platforming needs a proper test and cutover plan.

Organisations leaving data centres or end-of-life hosting need a way to decide how much to change during the move. Changing nothing is fastest but preserves every problem and often costs more to run. Changing everything is a rewrite with all its risks. These two labels exist to make the middle options explicit: rehost when time is the constraint or the application will be retired soon; re-platform when the application has years of life left and its infrastructure is the pain. The trade-off is always the same: effort and risk now against run cost and agility later.

• Rehosting a manufacturer's ERP VM to the cloud within a quarter to exit a hosting contract, then re-platforming the database the following year.
• Re-platforming a fintech's monolith onto containers with a managed Postgres so it can scale for month-end volumes.
• Moving a university portal to object storage and a managed database ahead of a modernization programme.
• Containerising a hospital's reporting service to run alongside new AI services in the same VPC.
• Lifting a logistics firm's legacy TMS unchanged because it is scheduled for replacement within eighteen months.

ConceptA decision framework rather than a single technique. Eazyware assesses which option fits each application during modernization scoping and executes either as part of Legacy-to-AI Modernization, usually re-platforming the pieces that unblock AI integration first.

Eazyware service that covers it: Legacy-to-AI Modernization Program. Starting prices are on the pricing page.