Are You Renting Your IT — or Owning the Outcome?

Here is a thought experiment worth running before your next renewal. Your MSP relationship ends tomorrow — amicably, even. Full cooperation, honest offboarding, everyone shakes hands.

What do you still have?

The inventory of what leaves

Walk through it honestly. The RMM agents get uninstalled, and with them go the monitoring baselines, the patch policies, the maintenance scripts, the alert thresholds — none of which ever lived in your environment. They lived in the MSP's multi-tenant console, as their configuration of their platform, applied to your machines. The automation that handled onboarding? Written in their PSA, against their workflow engine. The documentation — network diagrams, credentials, vendor contacts, the tribal knowledge of how your environment actually works? In their IT Glue instance, on their tenant, exported to you (if the offboarding clause is honored) as a stack of PDFs that no system can execute. The ticket history, with every resolution note and root cause your fees paid to discover? Theirs.

Now name what remains. In most engagements the answer is: hardware, licenses, and whatever undocumented state your machines happen to be in on the last day. Ten years and a million dollars of managed services, and the accumulated IT capability rounds to zero — because the capability was never built in your environment. It was rented from an adjacent one.

Opex forever, equity never

Every dollar you've spent on managed services was operating expense that improved the provider's asset — their configured platform, their documented knowledge of your environment, their renewal leverage. None of it was capital improvement of yours. The model is engineered this way: the franchise platforms are multi-tenant by design, which means your environment's brain is architecturally required to live in someone else's building.

This is also why the model suppresses internal IT value so effectively. Your team never learns the environment, because the knowledge lives somewhere they can't log into. Hiring an internal IT lead adds little, because there's nothing internal to lead — no runbooks in your repository, no policies in your consoles, no history in your systems. The IT maturity of the business stays exactly where it was the day the first agent was installed: permanently junior, permanently dependent.

And the switching cost that dependency creates isn't a bug in the franchise model. It's the retention strategy. Ask any MSP owner what their business is worth and they'll tell you the multiple is paid on recurring revenue under contract — which is to say, on the difficulty of leaving. Your lock-in is literally the asset on their balance sheet.

The other way to build it

Contrast that with an environment built the other way: device management as Intune policy in your tenant. Identity and conditional access in your Entra. Provisioning as Autopilot profiles you own. Security baselines, compliance policies, automation runbooks, and documentation living in systems where your name is on the tenant and your admins hold the keys.

In that architecture, the operator becomes swappable and the configuration becomes equity. You can change providers — or bring capability in-house, or split the work between them — without touching the machinery, because the machinery is yours. Every year of good operations compounds into an asset you keep: cleaner policy, better documentation, institutional knowledge that survives any vendor's departure. The provider's job changes from owning your environment to operating an environment you own — and providers who accept that job have to win the renewal on performance, because the exit costs nothing.

Notice what this does to the sales conversation. A provider building in your tenant is handing you leverage with every sprint. A provider building in their console is collecting it. Both will call themselves your partner. Only one is priced like it.

The ownership test

The test is binary, and it's worth writing into your next renewal negotiation as a condition rather than a question: either your environment gets more valuable every year you pay for management, or your dependency does. There is no third option, and the franchise model only offers one of the two.

So make your tenant the system of record, effective immediately. All new configuration happens in systems you own — patch rings in your Intune, not their RMM; documentation on your tenant, not their IT Glue; scripts and runbooks in your repository. Grandfather nothing: make migration of existing configuration into your environment a written condition of continuing, and watch how the provider reacts. A partner will agree. A franchise will explain why it's complicated.

That reaction is the whole diagnosis, compressed. Across this series we've traced the traditional MSP model to its source — a rented playbook, a stack that duplicates the platform you already own, a ticket queue whose economics reward volume, a third-party-access plane sitting under your zero trust, and an ownership structure where a decade of fees builds no asset you keep. None of it is fixable without changing the terms, because every fix reduces the revenue the model is engineered to protect.

The alternative is a different category of arrangement: management native to the Microsoft platform you already own, an AI-first service desk that resolves work instead of triaging it, and physical device logistics no software stack covers — all of it configured in your tenant, compounding into your equity. Once that layer is yours, the higher-level relationship becomes a choice rather than a dependency. Keep your MSP for the work they do well, right-size the scope on the work you've now internalized, or change providers entirely. The point isn't which of those you pick. The point is that you're the one picking.