A cloud move can be quick and still leave you with a costly, hard-to-run system. The right cloud migration strategy depends on each workload, so here are nine options and when they fit.
1. Lakeway Web Development — Custom Application Development for Cloud-Ready Growth
Lakeway Web Development builds custom, responsive web and mobile applications with modern tech stacks, system integration, and scalable architecture. This is a fit when your current application needs more than a change of hosting location, or when an older system blocks a planned cloud move.
For example, a mid-size firm might rely on an internal web app that doesn't work well on mobile or share data with its customer system. A custom rebuild can address those workflow gaps while the team plans where the app and its data should run. Cloud migration and application development are related, but they aren't the same service. Lakeway's work centers on custom application design and development, not a claim to migrate every type of infrastructure.
We can help map the current process, define the needed integrations, and shape the app around how your staff works. That can include AI-powered search, such as a natural-language way to find a record, plus built-in security considerations in the design. Review our cloud application development approach if you're weighing a custom application alongside infrastructure changes.
The tradeoff is time and design effort. If an existing app is stable and the immediate need is to leave a data center, rehosting may be a better first move. If the app's structure is the problem, a custom path can put the business goal ahead of a like-for-like copy.
2. Rehost (Lift-and-Shift) — Move Workloads Quickly With Minimal Changes
Rehosting moves an application and its supporting workload to cloud infrastructure with little or no change to its code or design. It suits teams facing a firm data-center exit date, or those that need to move a stable system before they can modernize it.
A lift-and-shift move can reduce the amount of code work required up front. It also lets teams keep familiar application behavior during the move. IBM's explanation of rehosting describes it as a faster, less labor-intensive move than approaches that change the application architecture.
Speed has a tradeoff. An application designed for fixed on-site capacity may keep that design in the cloud, where the organization still pays to run and manage its virtual machines. Unoptimized workloads can cost more after a move if teams don't right-size capacity or make use of cloud features. Treat rehosting as a location change, not proof that the app is now cloud-native.
Before moving, map the systems the application relies on. Check network paths, data stores, scheduled tasks, and access rules. Agree on a test plan and rollback point so the team knows when to stop the cutover. Afterward, compare performance and resource use with the old environment before declaring the migration complete.
Choose this strategy when speed and minimal application change matter more than immediate cloud optimization. Set a separate review date to decide whether the moved workload should stay as-is, be replatformed, or be retired.
3. Replatform — Make Targeted Changes Without Rebuilding the App
Replatforming moves an application while making limited changes to use managed services or other cloud features. It's often the middle path for teams that want lower operating effort without a full rewrite.
A common case is moving a self-managed database to a managed database service. The application may need configuration changes, but the team doesn't replace its core business logic. Another case is packaging an existing application in a container so deployment and scaling are easier to manage.
AWS migration guidance describes replatforming as a move with some optimization for cloud capabilities. It also notes that managed platforms can reduce work such as provisioning, patching, and backups. Those tasks don't disappear entirely, but the provider takes on parts of the underlying platform work.
Replatforming takes more planning than rehosting. You need to check whether the new service supports the app's version, data needs, and integration patterns. The team also needs skills to configure and operate the target service. A database move can expose assumptions in connection strings, backup routines, or maintenance windows, so test those before the live switch.
It can be a sound choice when a small technical change removes a recurring operational burden. Keep the scope narrow. If the proposed changes start altering core business rules or splitting the application into separate services, you're moving toward refactoring.
4. Refactor or Re-architect — Redesign for Cloud-Native Capabilities
Refactoring changes an application's code or architecture so it can make fuller use of cloud services. It fits when the current design limits growth, reliability, or the ability to add features.
Consider a single application that handles customer records, reporting, and order intake in one codebase. A redesign might separate those parts so each can be changed or scaled on its own. That can make releases more flexible, but it also adds design, testing, and ongoing support work. The new architecture still needs clear ownership and monitoring after launch.
Some organizations also use a migration as a chance to add cloud-native services that support analytics or AI features. Those capabilities require suitable data, security controls, and integration work; moving an application alone won't supply them. A refactor is a business and engineering choice, not a checkbox for cloud adoption.
Lakeway Web Development can support custom application work when an existing app needs redesign or new system links. Our software reengineering services overview can help you assess whether targeted changes or a larger rebuild better match the system's limits.
The main caveat is scope. Avoid promising a large redesign and a fixed migration date before you understand dependencies and team capacity. If the workload needs to move now, you may migrate it first and modernize it in a later phase.
5. Repurchase or Replace — Move to a Different Product or SaaS Service
Repurchasing replaces an existing application with a different product, often a software-as-a-service (SaaS) service. It fits when the current product is costly to maintain and a replacement can meet the business need.
A customer management system is one example. A company may decide it no longer wants to run the application on its own servers and instead move to a SaaS product. The work still includes more than copying records. Teams need to check which data matters, how fields map to the new system, and which daily tasks depend on current workflows.
Plan for user adoption as well as the technical move. Sales staff may need to learn a different way to log a customer interaction. Managers may need reports rebuilt to match new fields. Integrations with billing, email, or a website can also need changes. A replacement that looks similar on a screen may handle permissions or automation in a different way.
Before you commit, compare the full cost of the new service with the work and licenses it replaces. Review data export terms, access controls, and the process for leaving the SaaS product later. If it needs heavy customization to match the old app, that may weaken the case for replacing it.
Repurchase can reduce the need to maintain custom infrastructure, but it shifts some decisions to the SaaS provider. Choose it when the product fits your workflow without forcing your staff to work around it.
6. Retire — Decommission Workloads That No Longer Earn Their Keep
Retiring means turning off a workload that no longer supports a business need. It fits when an application is unused, duplicated, or no longer worth the cost and effort of keeping it.
Migration discovery often reveals old test systems, duplicate reporting tools, or apps that staff stopped using years ago. Moving all of them would add avoidable work. Retiring a verified workload can reduce the number of systems in scope and the effort needed to secure and operate the rest.
Confirm dependencies before shutting anything down. An application that seems inactive may still feed a report, hold records needed for an audit, or run a scheduled export. Ask the business owner to confirm the use case. Check logs and integrations, then decide whether to archive data, retain it under policy, or delete it safely.
Record the decision and update the application inventory. Also remove related access and infrastructure only after the owner approves the shutdown. This avoids leaving behind a database or service that still costs money or creates a security concern.
Retirement is the right choice only when the workload has no remaining business purpose or critical dependency. If there is doubt, retain it temporarily and set a date to review the decision.
7. Retain — Keep Workloads On-Premises for a Deliberate Reason
Retaining means leaving a workload in its current environment for now. It suits systems with a clear reason to stay, such as a technical dependency, a recent upgrade, or a business need that doesn't justify moving it yet.
Some older applications rely on hardware or software that has no ready cloud equivalent. Others may be stable and meet current needs, while a migration would add cost without a clear business gain. Keeping a workload in place can also be part of a hybrid setup, where some systems remain on-site and others move to cloud services.
Retain shouldn't mean forget. Write down why the workload stays, who owns it, and what would change the decision. A vendor releasing a compatible SaaS option could make replacement possible later. A new business need could justify replatforming. A clear revisit date keeps the choice from becoming permanent by default.
Check the system's security and support status while it remains in place. The team still needs a plan for access, backups, updates, and incident response. Keeping a workload on-premises doesn't remove those duties; it keeps them with the organization.
Use retain when the case for change is weak or a known blocker remains. Pair the choice with a trigger for reassessment, rather than putting the workload on an open-ended list.
8. Relocate — Move a VMware or Cloud Workload With Limited Redesign
Relocation moves infrastructure to another environment with little change to the application or day-to-day operations. It can fit a VMware estate moving to a supported cloud environment, or workloads moving between cloud environments.
Unlike a standard rehost, relocation can preserve more of the existing virtualization setup. This may matter when teams need to move virtual machines while keeping familiar management processes. It doesn't mean every workload will move without changes: network design, storage, permissions, and licensing still need review.
Relocation can help when the goal is to exit a data center or consolidate infrastructure without redesigning every application first. Keep the destination environment in view. If the move reproduces the same operational limits, the organization may still need a modernization plan after cutover.
Test a small group of workloads before setting the migration wave. Confirm that the target can handle the applications' dependencies and that staff can monitor and support them there. Include a rollback plan for systems that cannot meet performance or access needs after the move.
Choose relocation when continuity of the existing operating model matters. Choose replatforming instead when you want to make targeted changes to reduce platform management at the same time.
9. Cloud Repatriation — Move Selected Workloads Back to Private Infrastructure
Cloud repatriation moves selected workloads from public cloud to private infrastructure or managed colocation. It fits only when measured cost, performance, data location, or control needs support the change.
For example, a steady workload that runs all day may not gain much from elastic capacity. A service with heavy data movement may also face costs or performance limits that deserve a fresh review. First check whether rightsizing, workload scheduling, or a change to the design could address the issue without moving platforms.
Compare the full cost on both sides. Include infrastructure, staff effort, software, storage, network transfer, and the work needed to move data back. Estimate the effort to maintain the private environment too. A lower infrastructure bill can be offset if the organization needs new hardware or staff time to run it.
Repatriation isn't a blanket rejection of public cloud. A business may keep elastic services in public cloud while moving a steady or constrained workload elsewhere. The key is to set a clear reason for each workload's placement and test the exit path before a large transfer.
Use this option when the case is supported by workload-level evidence. If the issue is unclear ownership of cloud spend, fix cost tracking first so the placement decision rests on useful numbers.
Cloud Migration Strategy Comparison: Match Each Option to Its Best-Fit Workload
A cloud migration strategy comparison works best at the workload level. The same organization can rehost one application, replace another, and keep a third on-site. The table below connects each option to its main decision and the point to check before approval.
| Option | Best fit | Main tradeoff | Check before deciding |
|---|---|---|---|
| Lakeway Web Development | Custom app redesign or new cloud-ready application | Needs design and development time | Is the application itself the problem? |
| Rehost | Stable system with a firm move deadline | May carry old operating costs forward | Will its current design run well in cloud? |
| Replatform | App that can benefit from a managed service | Needs testing and platform skills | Does the target service support its dependencies? |
| Refactor | App limited by its current architecture | More build and test work | Is the expected business gain worth the effort? |
| Repurchase | Function met by a suitable SaaS product | Changes workflows and vendor relationship | Can data and integrations move cleanly? |
| Retire | Unused or redundant workload | Risk of missing a hidden dependency | Has the business owner approved shutdown? |
| Retain | Workload with a current reason to stay | Requires ongoing support in place | What event will trigger a review? |
| Relocate | Infrastructure move with limited redesign | Can preserve old operating limits | Can the target support current operations? |
| Repatriate | Workload with a measured case for private hosting | Requires an exit and new operating plan | Does full cost support moving it back? |
The table is a starting point, not a scorecard. Set the business goal first, then test each workload against its dependencies, cost pattern, and useful life. The best choice is the least complex option that still meets the goal.
What to Check Before Committing to a Cloud Migration Strategy
Before approving a migration, build a clear picture of the workload and the business change it needs. A cloud migration strategy should cover more than the destination. It needs an owner, a reason to move, and a way to confirm the result.
Inventory applications and dependencies
List the applications, data stores, integrations, scheduled tasks, and user groups in scope. Talk with the people who use each system. Automated discovery can show connections, but staff may know about a spreadsheet, manual upload, or nightly job that doesn't appear in a network map.
Define goals and cost limits
State what the move should improve. That might mean ending a data-center lease, reducing time spent patching a database, improving response during busy periods, or making an app easier to update. Estimate the new operating cost as well as the migration work. Include data transfer, duplicated systems during cutover, support, and likely follow-up changes.
Plan security, governance, and skills
Agree on who manages access, encryption, backups, monitoring, and cloud configuration. Decide how teams will tag resources and review spend. Check whether staff have the skills to run the target environment, or whether they need training or outside help. Security remains a shared task: moving to cloud doesn't remove your responsibility for application settings and data access.
Use a phased lifecycle
Organize the work around discovery and assessment, planning, migration, and post-migration operation. Start with a pilot workload that tests the proposed process without putting a critical system at unnecessary risk. Use what the pilot teaches you to adjust the runbook before moving a larger wave.
AWS migration guidance describes assess, mobilize, and migrate phases, including readiness work and a first migration wave. Whatever framework you use, give each phase an owner and a clear exit check. For the data portion, our data migration best practices cover mapping, testing, validation, and support after launch.
Finally, decide how you'll measure success. Check that users can complete their normal tasks, data matches the source, integrations work, and the team can support the workload. Don't treat a successful transfer as a successful migration until the service works for the people who rely on it.
Cloud Migration Strategy FAQs
What is a cloud migration strategy?
A cloud migration strategy is the plan for moving or changing workloads to meet a business goal. It identifies what should move, how each workload should change, and how teams will test and operate it. The right approach may differ by application, since systems have different dependencies, costs, and support needs.
What are the main cloud migration strategies?
The main options include rehosting, replatforming, refactoring, repurchasing, retiring, retaining, and relocating. Some organizations also assess cloud repatriation for selected workloads. These approaches vary in how much they change the application and its operating model, so a portfolio can use several at once.
Is lift-and-shift the best cloud migration strategy?
Lift-and-shift is best when speed and minimal code changes matter more than immediate modernization. It can help a team move a stable workload before a deadline, but it may carry existing performance and cost limits into the cloud. Review the workload after migration and plan any needed optimization separately.
How do I choose a cloud migration strategy for an application?
Start with the business reason for the move, then check the application's dependencies, data, cost pattern, and expected useful life. Compare the time and skills each option needs. A stable system with a deadline may suit rehosting, while an app blocked by its design may justify refactoring or replacement.
What are the main phases of cloud migration?
Most migration programs include discovery and assessment, planning, execution, then operation and optimization. Discovery maps workloads and dependencies. Planning sets the target and test approach. Execution moves the workload in controlled waves. After launch, teams validate the service, watch costs, and fix issues users report.
Conclusion
Choose a strategy workload by workload, and don't assume that the fastest move is the cheapest one to run. Start with an inventory and a small pilot, then use what you learn to set the next migration wave. If your application needs custom redesign alongside that work, Lakeway Web Development can help you assess the development path.