The short answer
Lift and shift copies a workload to cloud infrastructure and keeps its operating model. Same OS, runtime, database engine, and admin habits. Refactoring changes code or architecture so the workload uses cloud services differently: managed databases, object storage, queues, containers, or serverless functions. One buys speed. The other buys a better fit.
Choose lift and shift when a fixed date or hardware risk dominates. Choose refactoring when the app will live for years and its design blocks releases, scaling, or cost control. Many teams rehost first, then refactor one seam at a time. The error is calling a lift and shift done at cutover and never scheduling the cleanup.
| Aspect | Lift and shift | Refactoring |
|---|---|---|
| What changes in the app | Usually nothing beyond config and drivers | Code, data access, deployment and runtime change |
| Time to first cutover | Short, driven by replication and test windows | Longer, delivered in slices |
| Upfront effort | Inventory, replication, network and cutover testing | Design, code changes, test coverage and data migration |
| Run cost pattern | Often high because sizing copies peak and idle capacity | Can fall with managed services and autoscaling |
| Operational model | Keeps existing patching, backups and admin habits | Moves to managed services, pipelines and infrastructure as code |
| Risk | Lower delivery risk, higher chance of carrying technical debt | Higher delivery risk, better long-term fit if tested |
| Skills needed | Migration tools, networking and OS administration | Software design, CI/CD, cloud services and testing |
| Best use | Deadline moves, packaged apps, unknown lifetime | Long-lived apps with scaling or release pain |
How lift and shift works
Lift and shift starts with an inventory: servers, OS versions, agents, open ports, scheduled jobs, certificates, service accounts, and network paths. Map dependencies next. Which app calls which database, which file share must be visible, which DNS name is hardcoded. Tools such as AWS Application Migration Service, Azure Migrate, and Google Cloud Migrate to Virtual Machines replicate a running server. You seed the target, keep changes in sync, then cut over in a short window.
At cutover, stop the source, let replication catch up, start the target, switch DNS or load balancer rules, and test. Check boot mode (UEFI versus BIOS), disk layout, drivers, and license portability. Right-size instances after the first week. Keep the source powered off but recoverable until the new system has handled a month end or a peak event. Record what you left unchanged. That list is your refactoring backlog.
How refactoring works
Refactoring starts with a boundary. Pick a slice such as authentication, order intake, reporting, or file handling, then put it behind a clear interface. The old code keeps serving traffic while the new code takes a growing share. That is the strangler fig pattern. For a monolith, extract a service or replace direct database writes with an API. For a batch job, replace a cron script with a managed scheduler and a queue.
The work touches code, data, and operations. Config moves to environment variables or a parameter store. Secrets move to a secret manager. Local file writes move to object storage. Deployments move to a pipeline with infrastructure as code, such as Terraform or CloudFormation. You need tests that prove the new path matches the old one, plus logs and traces that show where requests go.
Refactoring is not a rewrite by default. A rewrite discards years of edge cases nobody documented. Prefer small changes behind a release switch. Run old and new paths in parallel where data allows, compare outputs, and move one customer group at a time. Keep a route back until the new path has handled real traffic through a full business cycle.
When to choose lift and shift
Choose lift and shift for a hard deadline. A lease ends, a server room closes, or a vendor drops hardware support. You need the workload running elsewhere before the date, and a refactor cannot fit. It also fits a stable, low-change app that is not strategic. An internal tool used once a day does not need a new architecture. Copy it, monitor it, and revisit later.
Lift and shift is the sane path when you lack source code, tests, or vendor cooperation. A packaged line-of-business app may forbid code changes or support only a specific OS and database version. Copying the supported stack to cloud virtual machines may be the only supported option. Check the vendor support statement first. A move that voids support is not a bargain.
Use lift and shift as a phase. Set a review date and a cleanup budget. Tag every migrated resource with an owner and an app name. Without tags, the cloud bill and the security review become guesswork. A move with no follow-up leaves the same slow releases and manual runbooks, now on a monthly invoice.
When to choose refactoring
Choose refactoring when the current design limits the business. Releases take weeks because one change needs a full regression pass. Traffic spikes force bigger servers. The database is a single point of failure. A feature needs events, search, or mobile access the old design cannot provide. Copying the app would copy the constraint.
Refactoring fits when run cost and operations matter over the long term. Managed queues, autoscaling groups, and object storage remove patching work. A managed database handles backups and failover. Containers keep the runtime consistent across environments. These changes need new skills, new deployment habits, and a stronger test suite. Confirm you have those before you commit.
Do not refactor everything at once. Pick one seam with clear value and a measurable exit. A payment flow, a reporting pipeline, or a customer portal can be isolated. Leave the stable core alone until the new pattern proves itself. If the app has no tests, write characterization tests around the slice first. Refactoring without a safety net is a rewrite with a nicer name.
Costs and effort to consider
Compare total effort, not the first invoice. Lift and shift has lower build cost and a faster first cutover. It often carries higher run cost because instances are sized for peak, disks are overprovisioned, and old test servers stay on. Refactoring has higher build cost and a longer path to first release. It can lower run cost and release effort once stable. The break-even point depends on app lifetime and change rate.
Count the people work. Lift and shift needs migration engineers, network changes, and app owners for cutover tests. Refactoring needs developers, testers, a platform engineer, and product time to define new behavior. Both need security review, backup tests, and a rollback plan. Both fail on the same hidden dependency: a report that reads the database directly, a file share nobody documented, or a job tied to a server name.
Watch for double running. During a refactor, old and new systems may both run, which doubles some support and data sync work. During a lift and shift, source and target may both run until cutover, which doubles the patching surface. Plan the overlap window and the exit. Check data transfer cost, license portability, and support contracts.
If you need a decision document before committing, the Cloudverg Discovery and roadmap sprint at $9,500 fixed price runs two weeks and ends with a target architecture, a phased roadmap, and a fixed quote for phase one. It is one option. A staff engineer with a whiteboard can do the same job if you have the time and internal knowledge.
Frequently asked questions
Is lift and shift cheaper than refactoring?
It usually costs less to reach the first cutover because you copy the existing stack. The total can be higher if you keep oversized instances, manual patching, and slow releases for years. Compare build cost plus years of run and change effort, not the migration invoice alone.
Can you lift and shift first and refactor later?
Yes. That is a common sequence when a data center exit or lease deadline forces a move. Set a review date, tag resources, and name the first seam to refactor before the move ends. Without that plan, the temporary copy becomes permanent.
Does refactoring mean rewriting the app from scratch?
No. Refactoring changes a bounded part of the app while the rest keeps running. Use a strangler pattern, release switches, and parallel runs. A full rewrite is a separate, riskier choice that you should justify on its own.