Lift and shift vs. refactor vs. replatform vs. rearchitect

In this piece, we’ll be taking a look at these 4 modernisation patterns on 5 dimensions. 

• Definition: what makes a strategy this pattern and not any other? Where does the name come from?  
• Scope of change: which components get changed? What’s on the chopping block?
• Scope of benefit: how can you benefit from this strategy? Performance? Cost? What’re the drivers?
• Effort, cost and risk: What sort of project are you looking at? Deputising the internal cloud team for a week or uniting multiple departments in a cash-hungry, multi-month walk on the wild side?
• TTV (time to value): how long till it’s 1) finished 2) recouped its cost and puts you in the black
• And last but not least, the ideal use case: if the above isn’t enough to give you some idea – we’ll provide an example

Let’s get to it.

Lift and shift migration

Definition of lift and shift

Lift and shift simply means lifting an application (with no changes) from one infrastructure to another. This could mean:

• Between cloud platforms
• Between on-premise servers
• But most commonly it means from an on-premises environment to a cloud environment

Scope of change

Lift and shift really means taking an app as is and plonking it somewhere else with no optimisation for the new infra.

For example:

Moving a database from on-premises to RDS would not be lift and shift as that’s moving it to a higher level of abstraction.

Scope of benefit

As you can imagine, the benefits of lift and shift are limited to the basics. Those moving from on-prem to cloud, replacing components like for like without optimisation, can enjoy:

• Cloud-based provisioning of basic VMs (EC2 et al) which will be more elastic than on-prem though lack the punch of cloud-native models like serverless etc
• Improved uptime and availability (depending on previous set-up)
• Cloud-based savings: pay-as-you-go and/or reserved model
• A stepping stone on the journey toward modernisation

Effort, risk and cost

Effort

Requires your existing cloud or ops team. Can likely be done by 1-3 engineers, taking less than 4 weeks.

Risk

While cloud migration is not without its risks and challenges, lift and shift is certainly on the lower end.

Cost

Minimal. Migration tooling and usual staff costs in most cases. Plus, new infrastructure. Circa $50,000 USD over 2-6 weeks for an SME.

Time to value

To complete

1-8 weeks for a typical SME use case.

To see ROI

12-52 weeks for the same.

Ideal candidate for a lift and shift cloud migration

These fall into two camps. Stepping stones and endpoints. 

Stepping stones

Companies who’d like a foothold in the cloud with a view to later modernisation – often companies with initial budget and/or time constraints.

Endpoints 

Companies working with applications which aren’t going to be evolved much further, but which, perhaps due to shaky on-prem infra, would benefit from some of the basic QoL upgrades from the cloud.

Replatform migration

Definition of the replatforming migration process

This migration strategy is the next one up. Here you alter ancillary components to move core application processes to managed services. This might include:

• A database moving from on-prem or EC2 to RDS
• Using a managed load balancer

To do this, you update configuration values such as connection strings, environment variables and service endpoints to point toward the new infra.

Scope of change

In this migration process, you move functions to their managed cloud-based counterparts.

Scope of benefit

Replatforming allows you to access the next rung of cloud benefits, though without code and/or architecture changes, the true benefits of cloud native (serverless, event-driven architectures/auto scaling) remain out of reach.

• Access to managed services means significantly reduced operational costs and risk
• Access to basic cloud QoL improvements as above
• A further step toward full modernisation

Effort, risk and cost

Effort

This requires input from the infra and dev teams. You’ll need to provision managed services, update configs, and run integration tests. Typical timeline: 4–8 weeks for an SME workload.

Risk

Again, quite low. Main risk is in behavioral differences between self-managed and managed services, which is not a terribly steep learning curve.

Cost

Circa 75,000-150,000 USD depending on how much is done in-house, size and application, etc. Cost range for typical SME use case.

Time to value

To complete

4-8 weeks for a typical SME use case. Slightly longer minimum time vs. lift and shift as more is changing.

To see ROI

12-36 weeks for the same. Slightly quicker time to ROI as you’re unlocking more tangible operational improvements vs. just having the same problems in the cloud.

Ideal use case for a replatforming cloud migration strategy

Again, I will give the case for a stepping stone and an endpoint.

Stepping stone

A team with limited time or resources to refactor now, but a clear plan to modernise in phases and start reducing infrastructure overhead immediately.

 Endpoint

This migration approach would suit a company whose application is essentially sound but difficult to upkeep.

Its performance and cost are fine for the job, and there’s no need to evolve it, but the team are being held up patching, maintaining and generally babysitting it.

Deploying it to a managed cloud environment means no more worries.

The refactoring migration approach

Definition of the refactoring approach

This really means the other elements already covered plus code. But, crucially, it does not cover architecture changes.

This means we might enhance our deployment to cloud infrastructure by making code changes allowing:

• Externalised config for cloud portability
• Statelessness for scaling compatibility
• Structured logging for cloud monitoring tools

Scope of change

Here, we’re changing everything except the core architecture.

Scope of benefit

Here we start to get into more serious ‘you have a new app’ territory.

• Enabling horizontal scaling (running the app on any instance) via refactoring stateful logic such as file uploads, session handling, or temporary storage to use external, cloud-based services instead of local resources
• You can now integrate your app with CI/CD pipelines by restructuring code for testability, introducing automated test coverage, and separating build-time and runtime configuration
• You can enable modern dependency management by replacing legacy libraries or tightly coupled modules with supported, cloud-compatible packages that follow current standards
• Clearer separation of concerns – although you’re not ready to adopt a microservice-based architecture (that would mean re-architecting), you can still logically boundary your code for modularity, isolating responsibilities into cleaner components within the existing structure

Effort, risk, cost

Effort

This is a more serious undertaking with significant dev involvement, QA and compliance testing. This might involve 5-10 members of staff for 5-10 weeks at an SME or 20+ members of staff 12-36+ weeks at an enterprise.

Risk

Moderate to high. Code changes are inherently more complex and risky than merely deploying the same functions to managed services/the cloud. In the case of enterprises with more dependencies the risk is greater.

Cost

Between 200,000 and 1 million USD for small to mid-sized organisations. For enterprise-level refactoring efforts, the ceiling is often significantly higher.

Ideal use case for refactoring

Stepping stone

Refactoring is a good stepping stone or pause point when the next phase of modernisation is undermined by worries about the code base. If it’s very tightly coupled and poorly understood, it makes sense to refactor before re-architecting.

Endpoint

Refactoring can be an endpoint when an application doesn’t need to hit the extreme scalability or modularity needs of a cloud-native architecture, but it does need change, run, and keep alive.

The re-architecting migration

Definition of re-architecting

This is the big one. Essentially, it means we’re now also changing the application’s architecture. Or we’re re-architecting it. Who would have thought?

Architecture means

• The application’s structural pattern (e.g. monolith, microservices, event-driven)
• How its components communicate (e.g. HTTP, message queues, event streams)
• How services are deployed and scaled (e.g. containers, serverless, multi-region)
• How state is managed (shared vs. isolated)

A re-architecting means changing one or more of these systems as well as any other previously covered transformations.

Scope of change

Greens all the way down.

Scope of benefit

Re-architecting opens the door to all true cloud-native benefits:

Monolith to microservices

• Unlocks independent deployability, reducing the need for coordinated releases
• Improves fault isolation — one failing service doesn’t take down the entire system
• Makes it easier to test, maintain, and scale services independently
• Aligns system structure with team boundaries, increasing long-term delivery speed

Synchronous to asynchronous/event-driven

• Enables horizontal scaling through non-blocking, distributed workflows
• Supports better resilience and load handling under unpredictable traffic
• Decouples systems, making them easier to evolve in parallel

VM-based to serverless or container-native

• Allows use of cloud-native infrastructure like AWS Lambda or Kubernetes
• Reduces operational overhead through autoscaling, managed runtimes, and reduced idle cost
• Enables smaller, safer, and more frequent deployments

Effort, risk and cost

Effort

High. This is a complex, long-term programme, not a project. For SMEs, it may involve 12–24 weeks of work across 5–10 engineers. In enterprises, 20+ people may be involved across multiple teams, over 26–78 weeks.

Although it’s not uncommon for projects to run on far longer if they’re poorly planned.

Risk

High. You’re rebuilding the plane while it’s flying. Changes at this scale introduce risk across functionality, performance, team alignment, and delivery timelines, especially when dependencies aren’t clearly defined.

Cost

These might start at the 500,000 USD mark, but large-scale modernisation projects can get into the tens and even hundreds of millions of dollars territory.

Time to value

To complete

26–78 weeks, depending on team size, risk appetite, and scope.

To see ROI

78–104 weeks, depending on how quickly the benefits of modularity, scaling, and engineering speed compound.

Ideal use case for re-architecting

Since we can’t reimagine an app more thoroughly than this, there’s no stepping stone option.

Endpoint

Re-architecting is typically undertaken when you have scalability, velocity or compliance requirements beyond last-gen architecture. It’s the last one on the list. All depart here.

How we can help

At Just After Midnight, we’ve run the gamut of modernisations, from tentative lift and shifts to full-throttle re-architectings. We’ve helped global businesses like Grab take advantage of cloud-native technologies and many more move toward the next phase of their modernisation journey.

To find out how we could help you, just get in touch.