CIOPages

CIOPages · Trench Notes · Infrastructure

Moving workloads from on premises to the cloud

The work of moving workloads from your own servers to a public cloud: deciding what moves and how, the order of the work, moving the data, licensing and commitments.

Published November 10, 2026

What the job is

An on-premises to cloud migration moves applications, servers and data from hardware you run to infrastructure and services a cloud provider runs. Each workload moves as it is, moves with changes, is replaced by a SaaS product, stays where it is, or is switched off.

Start by naming the date that drives the move: a hardware refresh, a data center lease, a support contract or a software renewal. That date sets the pace. The choice of treatment for each workload sets the effort and the cost.

Move fast or change as you move

The main decision is how much to change each workload during the move. Changing less moves faster and carries existing problems into the cloud. Changing more takes longer and adds risk to every wave.

AWS advises against refactoring during a large migration. Its guidance is to rehost, relocate or replatform first and modernize after the migration is complete.

Microsoft's Cloud Adoption Framework adds a test for rehosting: rehost only when you are confident the workload will stay in its current state for at least two years. It also warns that rehosting does not fix existing performance, reliability or architecture problems.

The decision is per workload. The first useful output is a list of every application with one treatment and one owner.

The treatments

AWS lists seven migration strategies, the 7 Rs. Microsoft's Cloud Adoption Framework lists eight. It splits refactor and rearchitect, calls repurchase replace, adds rebuild and has no relocate.

TreatmentWhat it meansFits
RetireDecommission or archive the application.No business value in keeping or moving it
RetainKeep it in the source environment for now.Data residency rules, specialized hardware, mainframe or non-x86 Unix systems, a recent upgrade
RehostMove it without changing the application. Also called lift and shift.Stable workloads with no near-term need to modernize
RelocateMove servers to a cloud version of the same platform without changing the application.Large groups of servers on a platform the provider also runs
Repurchase or replaceSwitch to a different product, often SaaS.Applications with a mature SaaS alternative, such as CRM, HR and collaboration tools
ReplatformMove with some changes, such as SQL Server on a server to a managed database service.Workloads where a managed service removes operating system and database upkeep
Refactor or rearchitectChange the architecture to use cloud-native services.Applications the business needs to scale or change faster

Microsoft lists rebuild separately: redevelop the workload on cloud-native services. It notes that some workloads, such as a DHCP server, have to be rebuilt, and that Active Directory domain controllers are better deployed new in Azure than migrated.

The order of the work

  1. Discover the estate. Collect configuration and performance data for every server. Azure Migrate does this free of charge with an appliance deployed in your data center. Run discovery long enough to capture month-end and quarter-end peaks.
  2. Map dependencies. Record which servers talk to which. Azure Migrate includes dependency analysis for this. Applications that depend on each other move in the same wave.
  3. Find what to retire. AWS suggests checking for applications with average CPU and memory use below 5 percent, those between 5 and 20 percent over 90 days, and those with no inbound connections in the last 90 days.
  4. Assign a treatment and an owner to each application. Record the reason, so the decision can be revisited.
  5. Build the landing zone. Set up accounts or subscriptions, identity, network connectivity to your sites, logging, security controls and cost tagging before the first workload moves.
  6. Run a pilot wave. Move a few low-risk applications. Measure replication time, cutover time and the problems found after cutover. Those figures turn the plan into a schedule.
  7. Migrate in waves. Group servers by application. AWS Transform MGN, named AWS Application Migration Service until June 2026, groups servers into applications and applications into waves, and replicates at block level until cutover. Keep the source running until the owner accepts the move.
  8. Rightsize and commit. Adjust instance sizes against measured use in the cloud before buying long-term commitments.
  9. Shut down the source. Retire emptied servers and storage, and end their support contracts.

What takes longer than expected

  • Moving the data. AWS gives a formula for the theoretical minimum: 100 TB over a 1 Gbps link at 80 percent utilization, 24 hours a day, takes 11.57 days before real-world conditions. Run the calculation for your own data and circuits early.
  • Cutovers. AWS DataSync documentation notes that in large migrations, cutover activities can take up to 30 percent of overall migration time.
  • Shipping data on devices. AWS Snowball Edge is no longer available to new customers. AWS points them to DataSync for online transfer and AWS Data Transfer Terminal for uploading from their own devices. Azure Data Box ships devices with 120 TB or 525 TB of usable capacity, and Microsoft describes it as suited to more than 40 TB with limited network connectivity.

The detail plans leave out

  • Patching stays with you. Under the AWS shared responsibility model, customers running EC2 manage the guest operating system, including updates and security patches, and the security group firewall settings. For abstracted services such as Amazon S3 and DynamoDB, AWS operates the operating system and platform.
  • Data leaving the cloud. Inbound transfer to Azure is free, and AWS and Azure each include 100 GB of outbound internet transfer per month. Beyond that, outbound transfer is billed. Applications that send data back to on-premises systems or to users pay for it every month.
  • Backup and disaster recovery. The on-premises backup and recovery setup does not follow the workload. Design and test the cloud equivalent before the source is retired.

Licensing, commitments and compliance

  • Microsoft licenses. Azure Hybrid Benefit lets Windows Server licenses with active Software Assurance or qualifying subscription licenses cover Azure virtual machines. Each VM needs at least 8 core licenses, and the benefit lasts only as long as the Software Assurance or subscription term.
  • Microsoft licenses on other providers. Microsoft's Flexible Virtualization Benefit, from October 1, 2022, does not extend to its Listed Providers: Alibaba, Amazon, Google and Microsoft. On AWS, Windows Server bring-your-own-license requires EC2 Dedicated Hosts, licenses bought before October 1, 2019, and a version released before that date. SQL Server licenses with active Software Assurance are eligible for License Mobility.
  • Oracle licenses. Oracle's cloud policy covers AWS, Azure and Google Cloud. Two vCPUs count as one Processor license when multithreading is enabled, and the Processor Core Factor Table does not apply.
  • Commitments. AWS Savings Plans commit you to an hourly spend for one or three years (one year only for Database Savings Plans), and can be returned only within 7 days of purchase, in the same calendar month, and only up to a $100 hourly commitment. Buy them after rightsizing.
  • Double running. The source environment and the cloud both cost money until each wave is accepted and the source is shut down. Budget for the planned overlap and a slipped one.
  • Data residency. AWS lists data residency requirements as a reason to retain an application. Settle with legal which data may sit in which regions before choosing them.

Skills and operations

Running workloads in the cloud is a different job from running hardware. Train the operations team on the provider's identity, networking and monitoring before production moves, not after.

Cloud bills arrive monthly and change with use. The FinOps Foundation describes the work in three phases: inform, which gives visibility into cost and usage; optimize, which finds improvements; and operate, which carries them out. Assign that work to named people before the first wave, and tag every resource with an owner from the start.

Settle these first

  • What date drives the migration, and what happens if it slips?
  • Which applications will be retired, and who signs off?
  • Which applications will stay on premises, and why?
  • How long will the data take to move over your circuits?
  • Which licenses can move to the cloud, and on which provider?
  • Who owns the cloud bill, and how will costs be tagged?
  • Who patches and monitors the migrated servers?

Questions

Should we refactor applications during the migration?
AWS advises against it for large migrations. Rehost, relocate or replatform first, then modernize after the migration is complete.
When is lift and shift the right choice?
Microsoft's guidance is to rehost only workloads that are stable and will stay in their current state for at least two years. Rehosting does not fix existing performance or reliability problems.
Can we use our Windows Server licenses in Azure?
Yes, through Azure Hybrid Benefit, if the licenses have active Software Assurance or are qualifying subscription licenses. Each VM needs at least 8 core licenses.
Can we bring Windows Server licenses to AWS?
Only on EC2 Dedicated Hosts, for licenses bought before October 1, 2019, and versions released before that date. Windows Server is not eligible for License Mobility.
Sources. AWS Prescriptive Guidance, About the migration strategies: https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html; Microsoft Cloud Adoption Framework, Select your cloud migration strategies: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/plan/select-cloud-migration-strategy; Microsoft Learn, About Azure Migrate: https://learn.microsoft.com/en-us/azure/migrate/migrate-services-overview; AWS, What Is AWS Transform MGN?: https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html; AWS What's New, AWS Application Migration Service is now AWS Transform MGN (June 8, 2026): https://aws.amazon.com/about-aws/whats-new/2026/06/aws-transform-mgn-rebrand/; AWS DataSync User Guide, Estimating migration timelines: https://docs.aws.amazon.com/datasync/latest/userguide/datasync-large-migration-timelines.html; AWS, Snowball Edge availability change: https://docs.aws.amazon.com/snowball/latest/developer-guide/snowball-edge-availability-change.html; Microsoft Learn, Azure Data Box overview: https://learn.microsoft.com/en-us/azure/databox/data-box-overview; AWS, Shared Responsibility Model: https://aws.amazon.com/compliance/shared-responsibility-model/; AWS, Amazon EC2 On-Demand Pricing: https://aws.amazon.com/ec2/pricing/on-demand/; Microsoft Azure, Bandwidth pricing: https://azure.microsoft.com/en-us/pricing/details/bandwidth/; Microsoft Learn, Azure Hybrid Benefit for Windows VMs: https://learn.microsoft.com/en-us/azure/virtual-machines/windows/hybrid-use-benefit-licensing; Microsoft Licensing, Easily bring your licenses to the cloud: https://www.microsoft.com/licensing/news/options-for-hosted-cloud; AWS, Microsoft Licensing on AWS FAQ: https://aws.amazon.com/windows/faq/; Oracle, Licensing Oracle Software in the Cloud Computing Environment: https://www.oracle.com/assets/cloud-licensing-070579.pdf; AWS, Savings Plans FAQ: https://aws.amazon.com/savingsplans/faq/; FinOps Foundation, FinOps Phases: https://www.finops.org/framework/phases/

Keep reading

Buyer Guide
Cloud Migration & Modernization Platforms
Checklist
Cloud Migration Readiness Checklist

Validate readiness before migrating workloads to the cloud.

Assessment
Cyber Resilience Posture

How Resilient Are You — Not Just How Secure?

Infrastructure
Decommissioning a data center