Cloud Migration Strategy: A Step-by-Step Plan for Mid-Sized Businesses

The call that starts most cloud migration strategy conversations usually comes on a Friday afternoon. First, the air conditioning in the server closet fails again. Then someone notices the nightly backup job has not finished cleanly in over a week. On top of that, the one person who really understood the ERP database left the company in the spring. Eventually, somebody in leadership says what everyone is thinking: “Why don’t we just move all of this to the cloud?”

I have spent most of my career as a cloud solutions architect, and for the last several years I have served as the lead architect on migration programs for companies with somewhere between 100 and 1,500 employees. That middle ground is where I have learned the most, because midsized businesses carry enterprise sized complexity with small business sized teams. For example, they typically run anywhere from 40 to 200 applications, a couple of databases nobody wants to touch, and an IT department of maybe five or six people who are already stretched.

However, “move everything to the cloud” is a wish, not a plan. A cloud migration strategy, on the other hand, is a plan. In my experience, the gap between those two things is the gap between a project that pays for itself and one that ends with a bigger monthly bill, the same old problems running on someone else’s hardware, and a leadership team that no longer trusts IT’s estimates.

So what follows is the plan I actually use with clients. Of course, it is not the only way to do this. Still, it has survived real budgets, real auditors, and real users who simply want their reports to load on Monday morning.

Why Midsized Businesses Need Their Own Cloud Migration Strategy

Enterprise Cloud Migration Strategy Playbooks Do Not Fit

Most of the published guidance on cloud migration was written with large enterprises in mind. As a result, those playbooks assume you have a dedicated migration team, a Cloud Center of Excellence, and a consulting budget that runs into seven figures. Startups, meanwhile, were usually born in the cloud and never had to migrate anything at all.

Midsized companies, therefore, sit in an awkward spot between those two worlds. For instance, you have legacy systems with years of business logic baked into them, yet you do not have a bench of specialists to rewrite them. Similarly, you have compliance obligations but not a full time compliance team. In addition, every hour your IT staff spends on the migration is an hour they are not spending on the help desk, the network, or the next acquisition. That staffing squeeze is why many firms weigh the numbers in a managed IT services vs in-house cost comparison before they commit to a migration timeline.

The Money Is Real

The financial stakes are real, too. Flexera’s 2026 State of the Cloud research shows that cloud spending rises with company size, with large enterprises holding the top monthly tiers while smaller businesses mostly stay below $50K a month. That sounds modest until you factor in waste. The same research puts estimated waste at 29% of IaaS and PaaS spend, which breaks a five year run of improvement and is tied to the added cost complexity of AI and newer PaaS and SaaS services. Consequently, if your company lands at $30,000 a month and wastes that average share, you are throwing away more than $100,000 a year. For a midsized business, that is a salary or two.

In short, the strategy has to be built for your size: lean, staged, and honest about what your team can carry.

Step 1: Anchor Your Cloud Migration Strategy in Business Goals

Start With One Question

Before anyone opens a cloud provider console, I ask the leadership team one question: what has to be true in 18 months for this project to count as a success?

Usually, the answers fall into a few buckets. For example, a hardware refresh is coming due and nobody wants to sign another five year capital purchase. Alternatively, a colocation contract is ending. In other cases, disaster recovery is effectively a set of external drives in someone’s car. Sometimes the business is growing into new regions, or an acquisition just doubled the number of systems. Finally, some companies simply want to use data and AI tools that run better on cloud platforms.

Pick One Primary Driver for Your Cloud Migration Strategy

All of those are valid. The problem, however, is that each one leads to a different cloud migration strategy. A company escaping a colocation contract by a fixed date, for instance, will prioritize speed and rehost heavily. By contrast, a company chasing better analytics will spend more time replatforming databases. Unless you choose, your project will drift between goals and satisfy none of them.

For that reason, I push teams to write one primary driver and two or three measurable outcomes. Something like: “Exit the colocation facility by June 30, cut unplanned downtime on order processing in half, and keep total monthly run cost within 10% of today’s spend.” That sentence then becomes the tiebreaker for every argument later in the project.

This is not just my preference, either. Microsoft’s Cloud Adoption Framework begins with a Strategy phase designed to align cloud adoption with business goals by connecting business drivers to cloud outcomes. If you skip it, you end up migrating simply for the sake of migrating.

Step 2: Build an Inventory You Would Bet Your Job On

Why the Inventory Comes First in Any Cloud Migration Strategy

Every midsized company I have worked with believed they knew what was running in their environment. Nevertheless, every single one was wrong about something.

On one project, for example, we were two weeks from shutting down a server room when a warehouse supervisor asked why his scanners had stopped syncing in the test environment. As it turned out, an old FTP server, which did not appear on any diagram, was quietly receiving order files from the company’s second largest customer. Had we missed it, we would have broken a revenue stream on cutover night.

That is exactly why the inventory comes before the timeline. Cloudain makes the same argument, recommending that the first output of any migration plan be a current state inventory of every application, database, service, integration, and dependency in scope.

How to Run Discovery

To begin with, use automated discovery, but do not trust it blindly. Discovery tools such as AWS Migration Hub or Azure Migrate can assess workloads as part of an AWS or Azure migration. If you have not settled on a platform yet, our AWS vs Azure comparison walks through how to choose. Ideally, run discovery for at least 30 days so you capture month end processing, payroll runs, and any quarterly batch jobs. After that, sit down with the people who actually use the systems and walk through the results together.

What to Record for Every Workload

For each workload, I record the following:

• First, the business owner (a named person, not a department)
• Next, how critical it is and what an hour of downtime costs
• Then, data volume and growth rate
• Also, licensing terms, especially for Windows Server, SQL Server, and Oracle
• In addition, any compliance or data residency requirements
• Furthermore, every inbound and outbound integration
• Finally, who gets the phone call when it breaks at 2 a.m.

That last item sounds like a joke. In reality, though, it reveals the true support model faster than any diagram.

Step 3: Apply the 7 Rs Within Your Cloud Migration Strategy

The Common Vocabulary

Once you know what you have, every workload needs a decision. Fortunately, the industry has settled on a common vocabulary for this. AWS describes seven common strategies for moving existing applications and services to the cloud, known as the 7 Rs: Retire, Retain, Rehost, Relocate, Repurchase, Replatform, and Refactor (Rearchitect).

The 7 Rs in Plain Terms

Here is how I explain each one to a midsized business:

• Retire. Turn it off. In fact, this is the most underrated decision in the whole framework. In almost every portfolio I review, a meaningful slice of applications has no active users, duplicates another tool, or exists only because nobody was brave enough to unplug it.
• Retain. Leave it where it is for now. After all, some systems have hardware dependencies, latency requirements, or contracts that make moving them a bad idea this year.
• Rehost. Lift and shift the server as it is onto cloud infrastructure. It is fast, predictable, and low risk; however, you inherit all of the old inefficiencies.
• Relocate. Move a virtualized environment, typically VMware, to an equivalent cloud platform without converting it.
• Repurchase. Replace the application with a SaaS product. For example, your old onsite CRM or email server is a classic candidate.
• Replatform. Make targeted changes during the move, such as shifting a self managed SQL Server to a managed database service.
• Refactor. Redesign the application to be cloud native. Admittedly, this delivers the most long term value, but it also costs the most time and talent.

What Actually Happens in Practice

In practice, rehosting carries most of the load. Cloudtech, citing AWS field guidance, reports that rehost is generally the most popular strategy, with big legacy migrations frequently rehosting 70% or more of their applications. That matches what I see, and I do not consider it a failure. On the contrary, getting out of a failing server room quickly and then modernizing from a stable cloud foundation is often the smartest sequence.

Therefore, my advice for midsized companies is simple: be aggressive with Retire and Repurchase, pragmatic with Rehost and Replatform, and very selective with Refactor. Above all, save refactoring for the one or two applications that truly differentiate your business, and budget it like new development, because refactoring costs track closely with custom software development cost.

Step 4: Build the Business Case for Your Cloud Migration Strategy

Where Forecasts Go Wrong

This is where cloud migration projects quietly go wrong. Typically, someone builds a spreadsheet comparing the cost of a server rack against the list price of equivalent virtual machines, the cloud wins, and the project gets approved. Then, eighteen months later, the bill is 40% higher than the forecast.

Costs the Calculators Leave Out

A credible business case, therefore, includes costs that vendor calculators rarely highlight:

• Dual running costs. For six to twelve months, you will pay for your existing environment and the cloud at the same time.
• Data egress. Moving data out of the cloud, or even between regions, costs money.
• Licensing. Similarly, Windows Server and SQL Server licensing can swing your numbers dramatically depending on whether you bring your own licenses.
• Tooling. Backup, monitoring, and security tools that you may have previously bundled into hardware now carry their own price.
• Support plans from the provider also add up.
• Training and partner fees round out the list. If you bring in outside developers for replatforming or refactoring work, our software development outsourcing cost guide shows what to expect.

Benefits and Hidden Savings

On the other side of the ledger, include the benefits that never show up on a hardware quote. These include avoided refresh cycles, recovered floor space, reduced downtime, and the hours your team stops spending on patching physical boxes.

Moreover, there is money hiding in commitment discounts. SHI’s analysis of the Flexera findings highlights the continued underuse of commitment discounts such as Reserved Instances and Savings Plans, frequently because teams view them as inflexible or hard to manage. Personally, I never buy commitments on day one; nevertheless, I always plan for them once usage stabilizes.

My rule, then, is to never promise savings in the first year. Instead, promise stability, resilience, and a cost baseline. The savings come in year two, after optimization.

Step 5: Build the Landing Zone Before You Move a Single Server

What a Landing Zone Is

A landing zone is the foundation of your cloud environment: identity, networking, security guardrails, logging, and account structure, all set up before the first workload arrives. In other words, skipping it is like moving furniture into a house before the plumbing is finished.

In Microsoft’s framework, the Ready phase handles Azure purchasing, tenant setup, and both platform and application landing zones so the environment is prepared for workloads. Likewise, AWS has a similar concept, and teams often rely on AWS Control Tower to build a multi account structure for governance and security.

The Minimum Viable Landing Zone

For a midsized business, my minimum viable landing zone includes:

• To start, a single identity provider with multifactor authentication enforced for every human account
• Next, role based access control, so nobody works day to day with full administrator rights
• Then, separate accounts or subscriptions for production and nonproduction
• Also, a network connection back to your offices, either a VPN or a dedicated private circuit
• In addition, a mandatory tagging policy covering owner, environment, application, and cost center
• Lastly, centralized logging, plus budget alerts that email a real human

Security Comes First in a Cloud Migration Strategy

Always Beyond advises reviewing your security posture before migration so that controls such as multifactor authentication and role based access are part of the cloud environment from the start. I agree completely. After all, security bolted on afterwards is always more expensive and always weaker.

Once the landing zone is live, a pen test confirms the guardrails actually hold; our guide to penetration testing cost explains what to budget. And if your small team cannot watch the new environment around the clock, managed security services can cover monitoring and response while your staff focuses on the migration.

Step 6: Plan Migration Waves, and Make the First One Boring

How a Cloud Migration Strategy Prioritizes Workloads

Nobody should move everything at once. Instead, you group workloads into waves, and you move one wave at a time.

To decide the order, Microsoft’s guidance offers a useful lens. It recommends treating high value, low effort workloads as quick wins to move first, high value and high effort workloads as strategic investments needing careful resourcing, and low value, high effort workloads as ones to defer or avoid.

Why the First Wave Should Be Boring

In addition, I apply one more rule: the first wave should be boring on purpose. Non critical workloads with few dependencies are good early candidates because they build familiarity without threatening production, whereas critical systems with many integrations should wait until the team has operational confidence. For example, file shares, development and test environments, an internal wiki, or a reporting server are all good choices. Ultimately, the goal of wave one is not business value. Rather, it is learning how your team, your tooling, and your change process behave under real conditions.

Keep Dependencies Together

Dependency groups matter here as well. If the ERP application talks constantly to a database and a reporting server, then those three move together. Otherwise, splitting them across your on premises network and the cloud can introduce latency that makes the application feel broken, even when nothing is technically wrong.

Meanwhile, Microsoft suggests carrying out the current wave while planning the next, using the time spent migrating one group to prepare the following wave and research future candidates. As a result, that rhythm keeps momentum without overwhelming a small team.

Step 7: Rehearse the Cutover, Then Rehearse the Rollback

Where the Risk Lives

The cutover, when traffic moves from the old infrastructure to the new, is where most migration risk is concentrated, so the rollback procedure should be tested before the migration rather than during an incident. I learned this the hard way. Specifically, I once watched a rollback that existed only on paper fail at 3 a.m. because a DNS change took far longer to propagate than anyone expected. Since then, I insist on a full dress rehearsal for any workload that matters.

My Cutover Checklist

For important systems, my cutover checklist looks like this:

• First, lower DNS time to live values several days in advance
• Second, replicate data continuously, then validate it with checksums or row counts before go live
• Third, agree on a change freeze for the systems being moved
• Next, write explicit go and no go criteria, and name the person who makes the call
• Then, define exactly what triggers a rollback and how long you will wait before triggering it
• Finally, have business users ready to run smoke tests immediately after cutover

Communicate Before, During, and After

Equally important, communication matters as much as technology. Microsoft recommends sharing a detailed schedule with every stakeholder that covers timing, expected service impact, responsibilities, and contingency plans, and making sure technical staff are on call for the whole migration window.

Step 8: Put People at the Center of Your Cloud Migration Strategy

The Hardest Part Is Not Technical

Here is something nobody puts in the vendor brochure: the hardest part of a cloud migration is rarely technical.

For one thing, your system administrators are being asked to give up skills they spent years building. Similarly, the finance team suddenly receives a variable monthly bill instead of a predictable depreciation schedule. Meanwhile, end users discover that the shared drive they relied on has moved and their mapped drive letters no longer work.

As Wildnet Edge points out, cloud migration involves more than technology changes, because it also requires organizational change management, upskilling staff, revising processes, and aligning business goals with technical capabilities.

Three Practical Moves

Practically speaking, I recommend three things. First, build a training plan before the migration starts. Microsoft’s cloud adoption plan template, for instance, includes sections for a skills assessment summary, expert support engagements, and target certifications for each role. Second, rewrite your operations runbooks, because the shared responsibility model means some tasks disappear while new ones appear, such as reviewing identity permissions and watching the bill. Third, involve end users early, since explaining what is changing and why reduces resistance and brings workflow concerns to light before they become post migration problems.

Step 9: Make Optimization Part of the Cloud Migration Strategy

Why Cost Control Matters Now

The migration is not finished on the day the last server moves. In many ways, that is actually when the real work starts.

Indeed, cost control has become the dominant concern across the industry. Flexera’s 2026 report shows 68% of organizations still rank cloud cost optimization as their top initiative, ahead of migrating more workloads and improving financial reporting. Moreover, many of them have built teams for it. The same research found that 63% of organizations have an established FinOps team and 71% operate a Cloud Center of Excellence.

FinOps Habits for Midsized Teams

Of course, a midsized business does not need a dedicated FinOps department. It does, however, need FinOps habits:

• Wait about 30 days after each wave, and then rightsize virtual machines based on real utilization
• Also, shut down nonproduction environments outside business hours
• Buy reserved capacity or savings plans only once usage is stable
• In addition, review the bill monthly with both IT and finance in the room
• Finally, enforce tagging so every dollar maps to an owner

If you build these habits during the migration rather than after it, you avoid the painful “why did our bill double?” meeting entirely.

Cloud Migration Strategy Mistakes I Keep Seeing

After enough projects, patterns emerge. Below are the mistakes I see most often in midsized companies:

• Choosing the provider before defining the goals. In truth, the provider matters less than most people think, while the strategy matters more.
• Treating rehost as the final state. Lift and shift is only a starting point. Without a modernization roadmap, you are simply running yesterday’s architecture at tomorrow’s prices.
• Underestimating data. Large databases and file shares take longer to move than anyone expects, especially over a modest internet connection.
• Ignoring licensing until the invoice arrives. Instead, licensing should be a line item in Step 4, not a surprise in month six.
• Letting one person hold all the knowledge. Therefore, document everything, so your migration lead can take a vacation without the project stopping.

A Realistic Cloud Migration Strategy Timeline

Every environment is different. Even so, for a midsized business with 50 to 150 applications, a realistic timeline usually looks like this:

• Months 1 and 2: First, define goals, run discovery, map dependencies, assign a 7 Rs decision to each workload, and build the business case.
• Months 2 and 3: Next, build and secure the landing zone, finalize the wave plan, and start training.
• Months 3 and 4: Then, execute the pilot wave with low risk workloads.
• Months 4 through 12: After that, move the remaining waves, with core business systems usually landing in the second half.
• Ongoing: Finally, optimize costs, modernize priority applications, and decommission the old environment.

Some companies, of course, move faster when a hard deadline such as a lease expiration forces the issue. That is fine; however, it usually means more rehosting now and more modernization later.

Cloud Migration Strategy FAQs

What is a cloud migration strategy?

A cloud migration strategy is the plan that decides which applications and data move to the cloud, how each one moves, in what order, and how success is measured. In addition, it covers assessment, migration approach, landing zone design, cutover, and ongoing optimization. AWS offers a solid starting point in its overview of migration approaches.

How long does a cloud migration strategy take to execute for a midsized business?

Most midsized migrations take roughly 6 to 12 months from assessment to the final wave, depending on the number of applications, data volumes, and how much modernization you attempt along the way. Furthermore, breaking the work into waves keeps risk manageable. See Microsoft’s wave planning guide.

What are the 7 Rs of a cloud migration strategy?

They are Retire, Retain, Rehost, Relocate, Repurchase, Replatform, and Refactor. Each one describes a different way of handling a workload, from switching it off entirely to redesigning it as a cloud native application. For more detail, read the AWS Prescriptive Guidance.

Will moving to the cloud actually save my business money?

It can, but not automatically. In fact, savings depend on retiring unused systems, rightsizing resources, using commitment discounts, and building cost governance from the start. Without those habits, many companies end up spending more. Flexera’s research on cost management trends explains why waste remains so persistent.

Should a cloud migration strategy include hybrid cloud?

For many companies, yes, at least for a while. Because hybrid lets legacy systems stay on premises while newer workloads run in the cloud, it supports a gradual and lower risk transition. Idea 11 covers this approach in its best practices guide for mid enterprise businesses.

Do we need an outside partner for our cloud migration?

Not always. That said, most midsized IT teams benefit from experienced help during assessment, landing zone design, and the first few waves. Ideally, a good partner transfers knowledge rather than creating dependency. Cherry Bekaert discusses this in its article for midsize organizations, and our guide on how to choose a managed service provider covers what to look for in a partner.

Final Thoughts on Building Your Cloud Migration Strategy

The companies that succeed with cloud migration are rarely the ones with the biggest budgets or the most advanced engineers. Instead, they are the ones that know why they are moving, know exactly what they own, make deliberate decisions about each workload, and treat cost and people as seriously as technology.

So if you take one thing from this plan, let it be this: slow down at the start so you can speed up later. After all, two extra weeks spent on discovery and goal setting will save you months of rework and a few very uncomfortable budget meetings. Ultimately, a well built cloud migration strategy does not just move your servers. Rather, it gives your business a foundation it can grow on for the next decade.

References

Cloud Provider Frameworks

1. Amazon Web Services. “What is a Cloud Migration Strategy?” aws.amazon.com
2. AWS Prescriptive Guidance. “About the migration strategies.” docs.aws.amazon.com
3. Microsoft Learn. “What is the Microsoft Cloud Adoption Framework?” learn.microsoft.com
4. Microsoft Learn. “Plan your migration.” learn.microsoft.com
5. Microsoft Learn. “Migration wave planning.” learn.microsoft.com
6. Microsoft Learn. “Execute migration to cloud.” learn.microsoft.com
7. Microsoft Learn. “Cloud adoption plan template for migration.” learn.microsoft.com

Industry Research and Reports

8. Flexera. “Flexera 2026 State of the Cloud Report: The convergence of cloud and value.” flexera.com
9. Flexera. “Cloud cost management isn’t just about cutting waste.” flexera.com
10. SHI Resource Hub. “5 FinOps takeaways from Flexera’s 2026 State of the Cloud Report.” blog.shi.com
11. Cloudtech. “The 7 Rs of Cloud Migration: Strategies and Statistics.” cloudtech.com

Practitioner Guides

12. Cloudain. “Cloud Migration Planning: A Practical Guide for SMBs.” cloudain.com
13. Idea 11. “Cloud Migration Best Practices: A Guide for Mid Enterprise Businesses.” idea11.com.au
14. Always Beyond. “On Premise to Cloud Migration Strategy: Where to Start.” alwaysbeyond.com
15. Wildnet Edge. “Cloud Migration Strategy Checklist for Mid Sized Enterprises.” wildnetedge.com
16. DEV Community. “Cloud Migration Strategies: The 7 Rs of Cloud Migration.” dev.to
17. Cherry Bekaert. “Benefits of Cloud Migration for Midsize Organizations.” cbh.com