How MSPs Guide Clients Through Cloud Migration

For an MSP, a cloud migration is one of the most valuable engagements available, and one of the easiest to get wrong. Done well, moving a client to Microsoft 365, Azure, or a cloud-hosted application generates a meaningful project fee and then a long tail of recurring management revenue. Done poorly, it becomes a margin-destroying overrun that damages the client relationship. The difference between the two outcomes is almost entirely decided before the migration begins, in the planning, which is why the assessment matters more than the cutover.

Why Cloud Is a Growth Engine

The reason cloud migration is such a strong service line is the recurring revenue it creates downstream. The migration itself is project income, but the real value is what follows: ongoing management of the cloud environment, licensing, security, and backup, each a recurring service billed every month. A single migration can convert into years of managed revenue.

This is why migrations feed the broader managed-services model so naturally. The project lands the client on infrastructure you then manage, expanding the recurring revenue base while deepening the relationship. A client whose cloud platform you run is woven into your service in a way a helpdesk client never is, which makes migration both a revenue event and a retention event.

The Readiness Assessment Is Everything

The single biggest determinant of a migration outcome is the quality of the upfront assessment. Flexera and other industry research consistently find that organizations waste a large share of cloud spend, often around a third, primarily due to inadequate planning. A structured readiness assessment is what separates a clean migration from an expensive overrun.

Assess five areas before scoping anything: application compatibility, data volume and dependencies, network and bandwidth, security and compliance requirements, and user-change readiness. A cloud migration readiness assessment surfaces the compatibility problem in week one, when it is cheap to solve, rather than at cutover, when it is a disaster. Scoping from a real assessment instead of optimism is the discipline that protects both the margin and the client relationship.

Pricing, Risk, and Honest Advice

Migrations are typically priced as a fixed-fee or phased project based on the assessed scope, the number of users, applications, and data volume, with the recurring management and licensing priced alongside. Under-scoped migrations destroy margin when surprises emerge mid-project, so the recurring revenue should be part of the pricing conversation from the start, not an afterthought.

The two real risks are inadequate planning and poor user adoption, and both are managed before the cutover, not during it. A technically perfect migration still fails if people cannot work the new way, which makes change management as important as the technical plan. Finally, the best MSPs do not move every client to the cloud reflexively; some workloads favor on-premise or hybrid for latency or compliance reasons. Advising honestly from the assessment, rather than from a cloud-everything sales target, is exactly what builds the trusted-advisor relationship, and a migrated client should always leave with a matching backup and disaster recovery plan for their new environment.

The Six Rs: A Migration Decision Framework

Not every application moves to the cloud the same way, and the discipline that separates a planned migration from a chaotic one is deciding the strategy per workload before touching anything. Gartner popularized a framework, widely known as the six Rs, that gives an MSP a shared vocabulary for that decision: rehost (lift and shift the application unchanged), replatform (make minor optimizations during the move), repurchase (replace it with a SaaS equivalent), refactor (rearchitect it for the cloud), retire (decommission it because it is no longer needed), and retain (leave it where it is for now). Each path carries a different cost, timeline, and risk profile, and mixing them up is how scope estimates fall apart.

For a typical small-business client, the readiness assessment usually sorts the inventory into a handful of rehosts, several repurchases (the on-premise file server becomes SharePoint, the old phone system becomes a cloud PBX), and a short retire list of forgotten applications nobody has opened in a year. Refactoring is rare in the SMB segment because it is expensive and best reserved for custom software the business depends on competitively. Walking a client through which bucket each system falls into turns an abstract cloud project into a concrete, defensible plan, and the conversation itself demonstrates the kind of judgment that defines the vCIO role.

A Worked Migration Estimate

Numbers make the planning discipline concrete. Consider a 40-user professional services firm moving from an aging on-premise file server and a self-hosted email system to Microsoft 365 with files in SharePoint and OneDrive. The project scope breaks into discovery and assessment, tenant setup and security baseline, data migration of roughly 2 terabytes, mailbox cutover for 40 users, and two weeks of post-migration hypercare. An MSP scoping this from a real assessment can price the project as a fixed fee with a defined statement of work, rather than guessing at hours and absorbing the overage.

The part owners routinely underestimate is the recurring tail. After cutover, that same client generates ongoing per-user license revenue, monthly management of the new environment, security services layered on the M365 tenant, and backup of the cloud data. Over a three-year horizon, the recurring revenue from a well-run migration commonly dwarfs the one-time project fee several times over, which is the entire economic argument for treating the project as a customer-acquisition event rather than a standalone job. The migration invoice opens the door; the managed agreement behind it is the business.

A Worked Example: Sizing the Waste the Assessment Prevents

The waste figure is abstract until it is attached to a real cloud bill, so price it the way a client feels it. The share Flexera attributes to waste is roughly a third of cloud spend, which is the same as saying about 33 cents of every dollar a client sends to the cloud is being burned, mostly on planning gaps the readiness assessment exists to catch. Suppose the 40-user professional services firm from the migration estimate above settles, after cutover, into a steady cloud bill of $4,000 a month across Microsoft 365 licensing, the new tenant, security, and backup, a realistic run rate for a firm that size. That is $48,000 a year of cloud spend the MSP now manages.

Apply Flexera's one-third figure to that bill and the stakes of the planning conversation become concrete. If this firm were left to run its environment the way the average unmanaged organization does, roughly a third of that $48,000, about $16,000 a year, would leak to over-provisioned resources, idle test environments, and storage nobody cleaned up. The MSP that surfaced and prevented that waste in the design phase did not just save the client money once; it created a recurring optimization service worth defending. Recovering even half of that one-third, $8,000 a year on a single 40-user account, is a number a client notices on every invoice and a reason they stay.

Now scale the same logic across a book of business rather than one client. An MSP managing ten accounts of comparable size is overseeing on the order of $480,000 a year of client cloud spend, and Flexera's one-third waste benchmark implies roughly $160,000 of that is at risk to the planning and governance gaps the readiness assessment and ongoing optimization address. The MSP is not paying that bill, but it is the party best positioned to shrink it, which is precisely why cloud optimization converts so cleanly from a cost problem into a billable, recurring service. The assessment that costs a few hours up front is defending a five-figure waste exposure per client and a six-figure one across the book, which is the entire economic case for never scoping a migration from optimism.

The comparison that lands hardest with an owner is recurring waste against the one-time project fee. The $16,000 a year of avoidable waste on that single 40-user account recurs every year the environment runs, while the migration project that put the client on the cloud is billed once. Read over the same three-year horizon the estimate above uses, that is roughly $48,000 of avoidable cloud waste on one account, which on many migrations rivals or exceeds the entire project fee. The unglamorous governance work, right-sizing, shutting down idle resources, and cleaning up orphaned storage, is therefore not a cost-center chore the MSP absorbs; it is recurring value the client can see on every invoice, and the clearest reason the optimization service pays for itself.

The Hidden Costs Clients Never See Coming

The wasted cloud spend Flexera documents does not come from a single bad decision; it accumulates from costs that were never modeled. The most common is over-provisioning: clients (or inexperienced providers) size cloud resources for peak load and run them at peak prices around the clock, when most workloads idle overnight and on weekends. Egress fees are another surprise, the charges cloud platforms levy for moving data out, which can make a poorly architected backup or multi-cloud setup quietly expensive. Idle and orphaned resources, test environments nobody shut down and storage volumes detached from deleted machines, round out the list.

An MSP that surfaces these in the design phase, rather than on the client first surprising invoice, both protects the relationship and creates an ongoing optimization service. This is the discipline the industry now calls FinOps: treating cloud spend as a managed, continuously optimized line item rather than a fixed utility. Reserved-instance and savings-plan commitments, right-sizing reviews, and automated shutdown schedules are all recurring work an MSP can own, turning the cost problem Flexera quantifies into a billable service that pays for itself.

What Changed in 2025 and 2026

Two shifts have reshaped how MSPs approach cloud migration. The first is the rise of selective repatriation. After a decade of cloud-everything momentum, a meaningful number of organizations have moved specific high-volume, predictable workloads back to on-premise or colocation where the economics favor it, a trend industry analysts and high-profile engineering teams have documented openly. The lesson for an MSP is not that cloud was a mistake; it is that the honest, workload-by-workload assessment matters more than ever, because the right answer is now genuinely mixed.

The second shift is the pressure AI workloads put on cloud planning. Clients adopting AI tooling are discovering that data residency, governance, and the cost of moving large datasets all bear directly on where their systems should live, questions that land squarely in the migration conversation. An MSP that can speak to both the repatriation math and the AI-readiness of a client environment is having a far more strategic discussion than one selling a one-way ticket to a single cloud, and that is exactly the conversation that compounds into durable recurring revenue.

Sequencing the Cutover to Protect Adoption

Even a well-scoped migration fails if the cutover is sequenced badly, because the part the client experiences is not the data transfer, it is the day their tools change. The proven sequence is to pilot with a small, friendly group first, validate that mail flow, file access, and the line-of-business applications work end to end, then migrate in waves rather than flipping the whole company at once. Waves contain the blast radius of any surprise to a handful of users and give the help desk a manageable support load instead of a flood of simultaneous tickets on day one.

Communication carries the rest. Users told in advance what will change, given a short reference for the new way to find their files, and offered a clear path to ask for help adopt far faster than users who arrive Monday to an unfamiliar environment. The post-cutover hypercare window, a deliberately heightened support posture for the first week or two, is where adoption is won or lost, and it is also where the relationship either deepens into a managed agreement or sours into buyer regret.