12 November 2026
6 minutes read
A cloud migration strategy involves both business and technical decisions. It affects how much an application needs to change, how the move is planned and what costs and risks the organisation needs to manage. Applications have different requirements, so no single approach fits every workload.
Rehosting, replatforming and refactoring are common cloud migration strategies. This article explains the work each involves and what to modernise during the move or leave for later.
With rehosting, an application moves to cloud infrastructure with little or no code change. This can suit a tight deadline when the target environment is compatible and disruption needs to stay limited. Existing design and operational constraints usually remain.
Replatforming retains the application’s core design while adapting individual components to the cloud environment. For example, a self-managed database could be replaced by a managed cloud service. This may reduce routine maintenance effort, though compatibility checks and testing are still needed.
In cloud migration, refactoring usually involves modifying application code to address technical limitations or make better use of cloud services. Larger structural redesigns are often called rearchitecting. For .NET workloads, this may include modernisation.
Cloud providers group migration approaches differently. AWS’s 7 Rs list relocate and repurchase separately, while refactor and re-architect are grouped under one category. The Azure Cloud Adoption Framework distinguishes code refactoring from rearchitecting the application. In this article, “refactoring” covers code-level work, while larger structural redesigns are described as rearchitecting.
The table below compares the scope, use cases and trade-offs of each approach.
Approach | Scope of change | When it may fit | Main trade-off |
|---|---|---|---|
Rehosting | Move the application largely as it is, with few or no changes. | The application needs to move with limited disruption and is compatible with the target environment. | Existing design and operational limitations may remain. |
Replatforming | Make targeted changes to selected components while keeping the core application design. | The business wants specific cloud or operational benefits without a full redesign. | Requires compatibility work and testing. |
Refactoring | Modify application code; assess architectural redesign separately as rearchitecting. | The current design creates constraints that justify modernisation. | Requires more planning, effort and coordination; the value depends on the goals and scope. |
Use the table as a starting point. For each application, ask:
What business event is driving the move, and is there a fixed deadline?
What cost or limitation will remain if the application moves largely unchanged?
What business outcome would justify changing the code or architecture now?
Microsoft’s Cloud Adoption Framework recommends assessing each workload’s current limitations and business goals before selecting a strategy. Rehosting can preserve existing constraints, so include known performance, reliability or architectural issues in the decision.
A phased approach can also make sense. An organisation might rehost an application to meet a move-out date and plan modernisation for later. In that case, the plan should include a clear trigger for revisiting the application, such as a support deadline or a change in operating costs.
Take an application with a fixed move-out date. First, confirm that it is compatible with the target cloud. If so, rehosting can meet the deadline with limited change. After cutover, review performance, operating effort and cost. If a self-managed database creates unnecessary maintenance work, plan a move to a managed service. Refactor the code or architecture only when it blocks a defined business outcome. Set acceptance criteria for each phase.
Not every application needs to move. Retain an application temporarily when a dependency, compliance requirement or business deadline makes migration impractical, and set a date or event to review that decision. Retire it when its functions are no longer needed or another system has replaced them. Confirm ownership, data retention and integration impacts before shutting it down.
Decision item | What to record |
|---|---|
Business driver and deadline | The business reason for moving the workload and any fixed migration deadline |
Selected approach and scope | The chosen strategy and the components included |
Expected outcome and measure | The intended improvement and how it will be measured |
Cost assumptions | Migration effort and ongoing hosting and support costs |
Constraints, review trigger and owner | Dependencies, risks, the date or event for reviewing the decision, and who owns the follow-up |
Before planning an application migration to the cloud, identify assumptions that could affect the effort or technical route. For Azure workloads, check service compatibility and platform configuration. Azure development and consulting expertise can support this review.
What to check | Why it matters | Example finding |
|---|---|---|
Runtime and dependencies | Unsupported versions or components can block an unchanged move. | A runtime or database upgrade is needed before cutover, for example when the application runs on a version that is reaching end of support. |
Data and storage | Data volume, file storage and state affect transfer time and consistency. | A shared file store or final synchronisation step is required. |
Identity and security | Authentication, secrets and access rules must work in the target environment. | Identity or network policies need to be updated. |
Integrations and network | External systems, allowlists and latency can affect critical workflows. | An integration depends on a fixed IP address or private network route. |
Operations and recovery | Monitoring, backups and recovery objectives determine how the service will be run. | The current application has no tested restore or rollback procedure. |
Build and release | The team needs a repeatable way to deploy and configure the application. | Pipeline or infrastructure changes are needed before release. |
Microsoft’s .NET Support Policy confirms that .NET 8 and .NET 9 are now out of support. .NET 10 (LTS) is supported until 14 November 2028. Applications still running .NET 8 or .NET 9 should include an upgrade in the migration plan, even if they are rehosted.
A migration plan should define how the team will switch traffic, verify the application and respond if critical checks fail. For stateful systems, this may include a period of data replication, a final synchronisation step and a controlled window for writes to stop.
Agree the rollback trigger before release. It could be a failed business-critical workflow, data inconsistency or a service that does not meet an agreed recovery or performance target. Document who can call a rollback, how data changes will be reconciled and how the previous environment will remain available until the new one is accepted. A DevOps engineer can help prepare deployment, monitoring and recovery procedures.
Rehosting reduces the change required before the move, but it does not automatically reduce the cost of running the application. After cutover, review:
Over-provisioned resources. Servers are often sized for peak load or for hardware bought years ago. If those sizes are copied one to one, the cloud bill reflects capacity the application does not use.
Storage and data transfer. Large data volumes, backups and traffic leaving the cloud (egress) can add charges that were not visible on-premises.
Licences. Some software licences are priced differently in the cloud, and bring-your-own-licence options may have conditions. Check the terms for each product before cutover.
Always-on non-production environments. Test and staging environments that run around the clock can add significant costs, especially when they are only needed during working hours. Schedule them to shut down when idle, where this fits the team’s testing and deployment needs.
Managed services. Moving a component to a managed service in a later phase can reduce operational effort, but it adds a service fee. Compare it with the time your team spends today.
Track resource use for several weeks and review the monthly cloud bill. Adjust capacity to match actual demand. If the bill is higher than expected, investigate which resources or services are driving the cost.
Co:tunity is a SaaS platform for collaborative trendspotting and innovation. UKAD refactored its existing code to improve quality and performance, migrated the platform to Azure, and continued its development and support.
East Capital Group moved five websites from WordPress and Optimizely to a shared Umbraco CMS, with hosting centralised on Azure. The new setup reduced licensing and hosting costs and made content management across the sites easier.
Rehosting, replatforming and refactoring involve different levels of change, effort and risk. The right approach depends on the application’s condition, business goals, deadlines and operating costs. Before deciding, assess dependencies, target-environment fit and cutover requirements. If a full redesign is not justified now, a phased migration can make it possible to modernise the application later.
