When you should stop using a traditional MSP.

Most CEOs wait too long to switch their managed services provider.

It isn't because they don't know something is off. It's because switching feels harder than tolerating, and the cost of staying with the wrong partner is mostly invisible. The cost of leaving shows up as a project on someone's plate, with a timeline, a transition risk, and a question about whether the next partner will be any better. So the math gets done quietly, and the conclusion is usually the same.

I want to give the CEOs in this position a better framework for that math. Not "is my MSP bad." That's the wrong question, and it has a built-in defense mechanism: the firm has been there for years, the people are nice, the help desk is responsive enough, and switching is a hassle. You can answer "they're doing fine" to that question almost indefinitely.

The better question is whether the model the firm is built on still fits the business it's serving. If the business has outgrown the model, the model isn't the right model anymore, even if the people inside it are working hard.

This is a buyer's framework, not a vendor pitch. Most of my career has been on the buying side of these relationships. The reason I'm writing this is that I had a version of this framework when I was the one paying the invoice, and I trusted it. I just had to learn it by failing to act on it a few times.

The wrong way to think about this

The wrong frame is personal. "Is the firm doing a bad job?" carries a heavy thumb on the scale toward staying. The firm is, in most cases, competent at what it does. The people are people you've built a relationship with. The work is mostly getting done.

The better frame is structural. The traditional MSP model was built for a particular shape of business, doing a particular volume of work, in a particular threat environment. The model is excellent at what it was built to do. The question isn't whether the firm is competent at the model. The question is whether the model still maps to your business.

A model can be working as designed and still be the wrong model for where you are now. The transition isn't a verdict on the partner. It's a recognition that your business moved.

The framework

Six things to watch. Each one is observable in under a minute. You don't need to ask your MSP. You already know.

One. The quarterly review is about last quarter, not next year. If every standing meeting opens with "here's what tickets we closed, here's the uptime number, here's the cybersecurity headline of the month," the relationship is reactive by structure. A partner who can only look backwards at the same meeting cadence isn't going to surface the work that matters most: where your environment needs to go in the next twelve months and what posture you need to take to get there. Roadmap-grade conversations don't happen by accident. If they aren't on the agenda, they aren't going to start.

Two. You can't get a straight answer about your security posture. "We have you covered" is not an answer. Specific is the answer: when was the last patch cycle completed, what does your identity model look like, what was the most recent verified threat the operations center actioned, which of your controls maps to which compliance line your auditor cares about. If those answers require a follow-up call or arrive wrapped in marketing language, the controls probably aren't there in the shape you need them. Defense should be the default state of the system, not a thing you have to ask the firm to demonstrate.

Three. Tier-1 tickets that should resolve in minutes are resolving in hours. The simple known-fix work, the password reset, the printer that won't print, the laptop stuck on an update, isn't a question of human cleverness. It's a question of operational maturity. If those resolutions consistently take a half-day, the firm is bottlenecked on capacity the model can't grow into. Your team is paying for the bottleneck in lost hours every week, and nobody's putting that on the invoice.

Four. You're the one bringing AI and automation to the table. The technology partner who isn't proactively surfacing operational improvements isn't doing the strategic part of the work. If you've spent the last year asking your MSP "what about AI" and getting back generic enthusiasm or pilot proposals that never ship, the model doesn't have the operating capacity to deliver on those conversations. AI isn't extra. It's a basic operating advantage for a growing business, and your technology partner should be the one running the conversation, not waiting for you to push.

Five. You can't tell what you're paying for. A managed services invoice should be defensible to a CFO. If the line items don't map to specific outcomes you can name, or if you suspect there's an opaque margin on the tools you're billed for, the partner has gone opaque on you. Opacity is a smell. The right partner tells you, in plain language, what you're getting and what they're charging for it, and the math holds up under a five-minute conversation with your finance lead.

Six. You're carrying the institutional knowledge. If the runbook for your environment lives in someone's head and not in a documentation system the partner owns and maintains, your MSP isn't actually running your operation. The configurations, the credential model, the change log, the why-we-did-it-that-way notes: those should belong to the relationship, not to a person inside your company who happens to remember how things are wired. A partner that depends on your memory is a partner you can't actually rely on.

If three of these are true

The threshold I'd use is three.

One being true is normal. Every relationship has friction. Two being true is a yellow flag worth raising with the firm directly to see what they say. Three being true is structural. Three says the model doesn't fit the business anymore, and no amount of effort inside the existing relationship is going to fix the fit.

When three are true, start the conversation. Not the conversation with your MSP about whether they can improve. The conversation about whether the model can scale with where the business is going. Those are different conversations, and they have different outcomes.

The actually hard part

The mechanics of switching managed services partners are well understood. The new partner runs the discovery, builds the documentation, coordinates the handoff with the outgoing firm, and runs in parallel for a window to catch what got missed. The transition takes a few weeks and a clear point of contact on both sides. It's a project, not a leap.

The hard part isn't logistical. The hard part is making the decision.

Most CEOs wait until something breaks: a breach, a missed audit, a senior hire who walks because the IT is intolerable. The break becomes the forcing function that gets the decision made.

The framework above is what lets you make the decision before the break. That's the only part of this that matters.

If you've read this far and three of the six were true, you already know what to do. You've known for a while.

The question wasn't whether you should switch. The question was when you'd act.