Lift and shift vs re-platform vs re-architect: choosing the right cloud migration strategy

Short answer: Lift-and-shift moves a workload to the cloud unchanged (fastest, lowest risk, no optimization payoff). Re-platform moves the workload while adopting some cloud-native features (managed databases, managed app services, cloud storage) – moderate effort, real operational savings, the sweet spot for most SMB workloads. Re-architect rebuilds the workload to be cloud-native from the ground up (highest effort, highest long-term payoff, only justified when the application is core to the business and going to live for many years). For a typical small business migration, you do not pick one strategy for the whole project – you pick a strategy per workload, and the answer ends up being a mix of all three plus two additional options most SMBs miss: repurchase (replace the workload with a SaaS equivalent) and retire (turn the workload off entirely because nobody actually needs it). The right migration is the one that uses the cheapest strategy that delivers what the business needs for that specific workload, not the most ambitious strategy applied across the board.

This guide breaks down the five migration strategies that actually matter for SMBs (the cloud vendors talk about “6 R’s” but one of them is rarely the right answer for a small business), how to decide which strategy fits each workload, the real cost-vs-effort tradeoff for each, and the patterns that show up in almost every SMB cloud migration. The intent is to give you a decision framework you can apply per workload before you talk to a vendor – so when somebody quotes you a $40,000 lift-and-shift, you can ask the better question: “Which workloads actually need lift-and-shift, and which ones could be repurchased or retired instead?” For the parent service overview of what a managed migration engagement includes once strategy is settled, see cloud migration services for small business.

Cloud migration strategies at a glance

Strategy	What it means	Effort	Cost	Long-term payoff	When it fits
Retire	Turn the workload off, do not migrate at all	Lowest	Lowest (saves money)	Highest ROI per dollar	Workload is unused or has a SaaS replacement nobody bothered to remove
Retain	Leave the workload on-prem (for now)	Low	Stays the same	Avoids forced migration cost	Compliance, latency, or cost reasons make on-prem the right answer for this workload
Repurchase (replace with SaaS)	Drop the on-prem app, adopt a SaaS equivalent	Low to medium	Low one-time, ongoing SaaS subscription	High – you stop operating the app entirely	A mature SaaS replacement exists and the workflow can adapt
Lift-and-shift (rehost)	Move the workload to a cloud VM unchanged	Low to medium	Medium one-time, similar ongoing	Low – same operational burden, just in the cloud	Vendor lock-in, time pressure, or temporary stepping-stone
Re-platform (replatform)	Move workload + adopt some managed services	Medium	Medium to high one-time, lower ongoing	High – real operational savings without rewriting the app	Most SMB workloads where some cloud-native features are available
Re-architect (refactor)	Rebuild the workload as cloud-native	High	High one-time, lower ongoing at scale	Highest – if you actually need the scale or features	Custom apps that are core to the business, multi-year horizon

The strategy is always a per-workload decision, not a project-level one. A 40-person business might end up with two workloads retired, three repurchased to SaaS, two re-platformed, one lift-and-shifted (because the vendor only supports on-prem), and one retained on-prem (because it is regulatory). That mix is the answer, not a flaw in the plan.

The 5 R’s that actually matter (and the 6th that does not)

Cloud vendors talk about “6 R’s” or sometimes “7 R’s” of migration. AWS and Microsoft both publish frameworks. For a small business, only 5 of them matter in practice:

1. Retire – turn it off, do not migrate
2. Retain – leave on-prem
3. Repurchase – replace with SaaS
4. Rehost (lift-and-shift) – move unchanged
5. Replatform – move with some optimization
6. Refactor / Re-architect – rebuild cloud-native

The 6th R (sometimes “Relocate”) is moving an entire VMware environment to a managed VMware-on-cloud service. It exists, it is sometimes the right answer for a 1,000-person mid-market business with hundreds of VMs – but for most SMBs in the 15 to 250 employee range, it is overkill. Skip it.

The reason the framework matters is not the names. It is the honest framing that retire and retain are real options. Most cloud vendor literature pushes “every workload should move,” and most SMB cloud migrations end up with surprises because nobody asked “does this workload need to exist at all?” or “should this one stay on-prem?”

Lift-and-shift: when it actually fits

Lift-and-shift (rehost) means taking the workload as-is and running it on cloud infrastructure. Same OS, same apps, same configuration – just on someone else’s servers.

When lift-and-shift is the right answer

• Vendor lock-in. A line-of-business application where the vendor only supports specific on-prem configurations, has not built a SaaS version, and will not certify a re-platformed setup. Lift-and-shift is the only path that gets you out of the server closet without losing vendor support.
• Time pressure. End of hardware lease, server-room lease ending, decommission deadline, or hardware failure imminent. Lift-and-shift is the fastest path off-prem.
• Stepping-stone. You plan to re-platform or re-architect later but cannot do that work right now. Move the workload to the cloud first, then optimize from there.
• Application complexity unknown. Custom or legacy app where re-platforming requires understanding an unmaintained codebase. Lift-and-shift first, then evaluate optimization once the dust settles.
• Compliance familiarity. Some regulated industries have validated their security posture against a specific server configuration. Lift-and-shift preserves that posture during the migration; you re-validate later.

When lift-and-shift is the wrong answer

• You are doing it for everything. Lift-and-shift is a tactic, not a strategy. If 80% of your workloads are getting lift-and-shifted, you are paying cloud prices for on-prem operations.
• A SaaS replacement exists. Lift-and-shifting a workload when a mature SaaS equivalent exists is the most expensive long-term mistake in this list. You pay for the migration, you keep operating the workload, and you ignore the fact that somebody else built a better version that you could just buy.
• The workload runs on an unsupported OS. Windows Server 2008 or 2012 in the cloud is the same security risk it was on-prem, plus a cloud bill. Replace, retire, or re-platform – not lift-and-shift.
• The application is the business. If the workload is core to your business, has a 5-to-10-year horizon, and is custom-built, lift-and-shift wastes the chance to optimize during the most disruptive moment in its lifecycle.

What lift-and-shift actually costs

The trap most SMBs fall into: lift-and-shift looks cheap because the migration project itself is short. But the total cost is the migration plus the operational cost forever.

• Migration cost: Low to medium. The tooling is mature (Azure Migrate, AWS Application Migration Service, third-party tools like Carbonite Migrate). For a single Windows Server, expect $3,000 to $15,000 in project cost.
• Cloud running cost: Often higher than on-prem when you account for always-on VM sizing, storage tiers, and network egress. The “savings” do not materialize because you have not changed anything that costs money. The fix for a lift-and-shift bill that is climbing is not “another migration” – it is the cost-management discipline covered in cloud cost management for small business: how to stop overpaying.
• Operational cost: Identical to on-prem. You still patch the OS, manage backups, secure the workload, and respond to alerts. The cloud bill replaces the hardware cost; the labor cost stays.

A typical lift-and-shift from on-prem Windows Server to Azure VM ends up costing the SMB slightly more per year than the on-prem equivalent. The wins are availability, remote access, and removing the office server room – not cost savings.

Re-platform: the SMB sweet spot

Re-platform (sometimes called “replatform” or “lift, tinker, and shift”) means moving the workload to the cloud but adopting some cloud-native features in the process. The workload is recognizable – same logical architecture – but pieces of it are now using managed services instead of you running them.

Concrete examples of re-platforming

• Database: Move SQL Server from a VM to Azure SQL Database or Amazon RDS. The application still talks to a SQL endpoint, but you no longer run the database server, manage SQL Server patches, or handle backup configuration.
• Web application: Move a .NET web app from an IIS server VM to Azure App Service or AWS Elastic Beanstalk. Application code is unchanged, but you no longer manage the OS or web server.
• Identity: Move from on-prem Active Directory to hybrid identity with Entra Connect, then over time to cloud-only Entra ID. The user experience is unchanged; the operational burden of managing AD shrinks.
• File storage: Move a file server’s data to Azure Files or AWS FSx for Windows. Users still connect to a file share by SMB; you no longer maintain the file server.
• Backups: Replace an on-prem backup server with Azure Backup or AWS Backup. The backup workflow is similar; the appliance and the backup server VM go away.
• Email: This is technically repurchase rather than re-platform, but worth noting – moving from on-prem Exchange to Microsoft 365 is the most common SMB re-platforming move and the highest-leverage one. See how to migrate email to Microsoft 365 from an old Exchange server or Gmail for the execution.

When re-platforming fits

• The application supports running on a managed service (most modern apps, most vendor apps where the vendor has updated their certification matrix).
• You want some operational savings (less patching, automatic backups, easier scaling) without rewriting the application.
• You have time and budget for moderate refactoring during the migration (typically 20 to 50% more project effort than lift-and-shift).
• The workload is going to live for at least 3 to 5 years – long enough that the operational savings recoup the higher one-time cost.

What re-platforming actually costs

• Migration cost: Medium to high. Expect 30 to 80% more project effort than lift-and-shift. For a SQL workload, expect $10,000 to $40,000 instead of $5,000 to $15,000 for lift-and-shift.
• Cloud running cost: Often lower than lift-and-shift because managed services scale down during off-hours and right-size automatically. A managed database is often cheaper to run than the equivalent VM with SQL Server licensed by the hour.
• Operational cost: Substantially lower. The patching, backup management, and high-availability configuration that ate hours per month on-prem are now Microsoft’s or Amazon’s problem.

For most SMB workloads where re-platform is technically possible, the operational savings recoup the higher one-time cost in 12 to 24 months. After that, you are running the workload for genuinely less than on-prem ever cost. This is why re-platform is the sweet spot – the math works on a realistic SMB timeline, not just at hyperscaler scale.

Re-architect: when it is worth it (and when it is not)

Re-architect (refactor) means rebuilding the workload to be cloud-native from the ground up. This is the strategy you read about in vendor case studies: containerized microservices, serverless functions, event-driven pipelines, infrastructure-as-code from day one.

For most SMB workloads, re-architect is not the right answer. It costs 5 to 20 times more than lift-and-shift, takes 6 to 24 months instead of 6 to 12 weeks, and the cloud-native benefits (auto-scaling, regional failover, infinite elasticity) usually do not pay for themselves at SMB scale. A 40-person business does not need a microservices architecture for the practice management app.

When re-architect actually fits

• The application is core to the business. Re-architecting your scheduling system makes sense if scheduling is what your business does. Re-architecting an internal HR portal does not.
• The application has a 5-to-10-year horizon. Re-architecture pays back over years, not months. If the workload might be replaced in 18 months, re-architect is wasted effort.
• Current architecture is genuinely failing. The app cannot scale to handle current load, downtime is unacceptable, and the architecture itself – not the deployment – is the problem. If lift-and-shift or re-platform would solve the immediate pain, re-architect is over-engineered.
• You have engineering capacity. Re-architecture requires developers, not just ops. If you do not have a software team or a budget to hire one, re-architect is not on the table – this is a strategic constraint, not a failing.
• Compliance or feature gaps. Some new compliance requirements (PCI DSS 4.0, HIPAA hardening) are easier to meet on cloud-native platforms than on lifted-and-shifted VMs. Some new features (machine learning, real-time collaboration) require cloud-native infrastructure that lifted apps cannot tap into.

When re-architect is the wrong answer

• It is the default ambition. A vendor or internal champion who pitches re-architect as “the right way to do cloud” has not done the math for an SMB budget.
• The workload is generic. If your workload is “an off-the-shelf accounting package” or “an off-the-shelf CRM,” repurchase is the right strategy, not re-architect. Buy the SaaS version – somebody else has already done the cloud-native work.
• You are short on time. Re-architect is a 6-to-24-month project. If you are out of office space in 90 days, re-architect is not the strategy that helps you.

What re-architect actually costs

• Migration cost: High. Expect 5 to 20 times the cost of lift-and-shift for the same workload. A re-architected line-of-business app for a 40-person business commonly lands in the $150,000 to $750,000 range.
• Cloud running cost: Lower per-transaction at scale, but small workloads often do not benefit. The cloud-native architecture has fixed overhead (load balancers, multi-AZ deployments) that does not pay back at low traffic.
• Operational cost: Lower if you have invested in observability, CI/CD, and automation. Higher if you have not – cloud-native apps need cloud-native operating discipline.

Re-architect makes sense when the math works over 5 to 10 years and the workload is core to the business. For most other SMB workloads, you are better off with re-platform or repurchase.

Repurchase: the underrated strategy most SMBs miss

Repurchase (replace with SaaS) is the strategy SMBs most often skip because it does not feel like “migration.” You are not moving the workload – you are replacing it. But this is genuinely the highest-leverage path when it applies, because you stop operating the workload entirely.

Concrete examples

• On-prem Exchange → Microsoft 365 (Exchange Online via repurchase)
• On-prem CRM → HubSpot, Salesforce, or Zoho
• On-prem accounting (QuickBooks Desktop, Sage 50) → QuickBooks Online, Xero, NetSuite
• On-prem file server → SharePoint and OneDrive
• Self-hosted helpdesk → Freshdesk, Zendesk, ServiceDesk Plus
• On-prem ERP → NetSuite, Acumatica, Microsoft Business Central
• On-prem PBX (phone system) → 3CX cloud, RingCentral, Microsoft Teams Phone
• On-prem time-tracking → Toggl, Harvest, ClickTime

When repurchase fits

• A mature SaaS replacement exists.
• The data migration path is reasonable (not a custom export-and-rebuild project that costs more than the SaaS subscription saves).
• The workflow can adapt to the SaaS product’s conventions without losing critical functionality.
• The long-term operational savings (no servers, no patches, no backup management) justify the switching cost.

For the per-application execution side – how to evaluate a SaaS replacement honestly, what data migration actually involves, what to do when the vendor refuses cloud – see how to move line-of-business applications to the cloud.

Why SMBs miss repurchase

• It feels like a different project, not part of the migration. (“We’re migrating the server, not switching CRMs.”)
• Switching cost is real – data migration, user retraining, integrations to rebuild.
• Internal champions of the existing tool resist replacement.
• Vendor relationships exist for the existing tool and not the SaaS.

These are real concerns, but they are usually outweighed by the operational savings of getting out of operating the workload entirely. The right time to evaluate repurchase is during the migration planning phase, not after lift-and-shift has already happened.

Retire and retain: the two strategies nobody talks about

These are the strategies that get skipped because they are not “doing something.” They are doing nothing, or doing nothing yet. But ignoring them is how SMBs end up paying to migrate workloads that should not exist or do not belong in the cloud.

Retire

A workload that nobody uses, nobody owns, and nobody would notice missing for a week. Every SMB has them. The intranet site nobody visits. The reporting server that runs jobs nobody reads. The print server for a printer that was retired three years ago. The dev environment for a project that wrapped in 2022.

The trap: lifting and shifting these to the cloud out of inertia. You pay to migrate, you pay to run, and you pay to operate something that has zero value. The right strategy is to turn it off.

How to find retire candidates:

• Audit access logs. Workloads with no logins in 90 days are retire candidates.
• Survey users. “Did you use this tool in the last 30 days?” If the answer is no across the board, it is a candidate.
• Check ownership. Workloads with no current owner are usually retire candidates – somebody set it up, left the company, and it kept running.
• Decommission test. Turn the workload off for a week. If nobody complains, retire it.

Retain

A workload that should stay on-prem, at least for now. The right answer is not always “move it to the cloud.” Some workloads belong on-prem.

When retain is the right answer:

• Latency-sensitive workloads. Manufacturing systems, video editing, real-time control systems – if the application has hard latency requirements that internet transit cannot meet, on-prem is the right answer.
• Compliance-locked workloads. Some regulated environments (specific defense contracting, certain HIPAA configurations) have not yet been certified for cloud equivalents. The cost of certifying the move can exceed the cost of operating on-prem.
• Cost-prohibitive workloads. Workloads with massive storage and unpredictable access patterns can be more expensive in cloud than on-prem because of egress and tiering costs. Big data analytics, video archives, and certain rendering workloads sometimes fit this profile.
• Hardware-locked workloads. Apps that depend on specific hardware (USB security dongles, specialty acquisition boards, specific GPUs) cannot be moved to a cloud VM without losing the hardware dependency.

The “retain” strategy does not mean “never move it.” It means “not now.” Re-evaluate every 12 to 24 months as the workload evolves, the cloud equivalents mature, and the on-prem hardware ages. If one or more workloads end up on long-term retain, you are committing to a hybrid architecture rather than a pure-cloud destination – see hybrid cloud for small business: what it is and when it makes sense for what running hybrid deliberately actually involves.

How to decide per workload

The strategy is per-workload, not per-project. Here is the decision tree most SMB migrations follow:

1. Does anyone actually use this workload?

– No → Retire.

– Yes → continue.

1. Should this workload be in the cloud at all?

– No, latency / compliance / cost reason → Retain on-prem.

– Yes → continue.

1. Does a mature SaaS replacement exist that fits the workflow?

– Yes → Repurchase (and the rest of the migration becomes a data migration plus user training).

– No → continue.

1. Is the workload critical, going to live 5+ years, and currently architecturally limited?

– Yes, with budget and engineering capacity → Re-architect.

– No → continue.

1. Can the workload run on a managed service (managed database, managed app service, managed file share)?

– Yes → Re-platform.

– No → continue.

1. Default: Lift-and-shift.

This order matters. It biases toward strategies that eliminate operational burden (retire, retain, repurchase) and adopt cloud-native features (re-platform) before falling back to lift-and-shift. Most SMB cloud migrations would benefit from running their workload list through this tree before getting a vendor quote.

The opposite order – “lift-and-shift everything by default and re-architect later” – is how SMBs end up with cloud bills 30 to 60% higher than they should be, with no operational savings to show for it. See how much does cloud migration cost for a small business for the actual cost numbers behind these strategy choices.

A worked example: 40-person law firm

A typical 40-person law firm runs roughly the following workloads on-prem:

Workload	Recommended strategy	Why
Email server (Exchange 2016)	Repurchase (Microsoft 365)	Mature SaaS, lowest-risk move, foundation for everything else
File server (Windows Server, 800 GB of documents)	Repurchase (SharePoint + OneDrive)	SaaS replacement is mature; lifting the file server is the most expensive long-term mistake
Practice management application (vendor-only, on-prem)	Lift-and-shift to Azure VM	Vendor does not support cloud-native; lift-and-shift is the only path
Document management system (custom, 10 years old, no maintainer)	Repurchase (NetDocuments, iManage)	Mature legal-vertical SaaS exists; custom system is technical debt
Time and billing system	Repurchase (Clio, Centerbase)	Mature SaaS exists in the legal vertical
SQL Server (used by practice management + billing)	Re-platform to Azure SQL Database	If practice management vendor supports it; otherwise lift-and-shift with the app
Active Directory / Domain Controller	Re-platform (hybrid identity with Entra Connect, then cloud-only Entra ID)	Identity is foundational; hybrid is the safe path during transition
Print server	Retire (move to Universal Print)	Print server architecture is obsolete; Universal Print is included in many M365 plans
Backup server	Retire (replace with cloud-native backup)	The on-prem backup server itself is not the workload – the data is
Old SharePoint 2013 intranet (nobody updates it)	Retire	Survey shows nobody has used it in 6 months
Specialty discovery review tool (loads gigabytes of evidence per case)	Retain on-prem	Latency and bandwidth profile is wrong for cloud transit during active reviews

That mix – 4 retire/retain decisions, 4 repurchases, 2 re-platforms, 1 lift-and-shift – is what a real SMB migration looks like. Not “lift-and-shift everything to Azure,” not “rebuild everything as cloud-native.” A targeted strategy per workload, biased toward eliminating operational burden where possible.

The same 40-person business with a different industry vertical (a manufacturer, a construction company, a regional accounting firm) will end up with a different mix – but the decision tree is the same. Run each workload through it. The right strategy emerges per workload, not per project.

Common cloud migration strategy mistakes

1. Picking one strategy for the whole project. “We’re doing a lift-and-shift” or “we’re going cloud-native.” Both are wrong. The strategy is per workload.

1. Lift-and-shifting because it is fastest. Speed is a real constraint sometimes (lease expiring, hardware failing). But fast-and-cheap migration is rarely actually cheap once the cloud bill arrives. If you have to lift-and-shift for time reasons, schedule the re-platform or repurchase work as a follow-up project, not “someday.”

1. Re-architecting the wrong workload. Re-architecting an internal HR system because cloud-native is “the modern way.” Spend that engineering budget re-architecting something that customers actually use, or skip the re-architect entirely.

1. Skipping repurchase evaluation. Lift-and-shifting the on-prem CRM, the on-prem accounting package, or the on-prem helpdesk when SaaS equivalents are mature is the most expensive long-term mistake on this list. Always evaluate repurchase before defaulting to lift-and-shift.

1. Forgetting retire. Migrating workloads that nobody uses. Every SMB has these. The right cost of migrating an unused workload is zero. Find them in inventory; turn them off.

1. Forgetting retain. Forcing a workload to the cloud because “everything is going to the cloud” when latency, compliance, or cost reasons make on-prem genuinely better. The right answer is sometimes “leave this one alone for now.”

1. Picking strategy before inventory. Strategy is a per-workload decision. Without an honest inventory of what you actually have, the strategy decision is guesswork. See the cloud migration checklist for small business for the inventory step that has to come first.

1. Letting the platform pick the strategy. “We’re an Azure shop, so everything moves to Azure VMs” is platform-led, not strategy-led. The platform you pick (Azure, AWS, smaller managed providers) is a separate decision from the strategy per workload. See Azure vs AWS for small business for the platform decision.

1. Underestimating re-platforming. Re-platforming has more upfront effort than lift-and-shift, and SMBs often pick lift-and-shift to save the project budget without modeling the 24-month operational cost difference. Run the math.

1. Treating strategy as one-time. A workload lift-and-shifted today might be a re-platform candidate in 18 months when the vendor adds managed-service support. The strategy you pick at migration is the strategy for now, not forever. Re-evaluate every 12 to 24 months.

How long does each strategy actually take

Strategy	Typical timeline (single workload)	Typical timeline (full SMB migration)
Retire	1 day to 2 weeks	Built into project plan
Retain	No work	Decisions documented, re-evaluate at 12-24 months
Repurchase	2 to 8 weeks (data migration + user retraining)	8 to 16 weeks for a typical 40-person firm with 3-5 repurchases
Lift-and-shift	1 to 4 weeks per workload	4 to 12 weeks for a small workload set
Re-platform	4 to 16 weeks per workload	12 to 32 weeks for a 3-4 workload re-platform set
Re-architect	6 to 24 months per workload	Usually scoped as its own project, not bundled

A typical SMB migration that combines all five strategies (a few retires, a few repurchases, a few re-platforms, one lift-and-shift, no re-architect) lands in the 3-to-9-month range from project kickoff to old systems decommissioned. See the cloud migration checklist for small business for the project-management spine that holds these strategies together, and how much does cloud migration cost for a small business for the dollar figures that go with each strategy at SMB scale.

How Sequentur can help

If you are weighing migration strategies for your environment and want help mapping each workload to the right approach – or just a second pair of eyes on a vendor’s recommended plan – schedule a call.