When to Fire Your Managed Service Provider


I had a conversation last week with a CFO who was confused about why IT costs kept climbing despite outsourcing everything to a managed service provider three years ago. Their MSP bill had grown 35% year over year, incidents weren’t resolving faster, and the internal team spent half their time managing the MSP instead of doing actual work.

I hear some version of this story every month. MSP relationships go stale or adversarial more often than anyone admits. And because switching costs feel enormous, companies stay in bad arrangements for years longer than they should.

The Warning Signs

You’re managing your manager. If your internal team spends more than 20% of their time overseeing, escalating, or correcting the MSP’s work, you’re paying twice for the same outcome. An MSP should reduce your management burden, not increase it.

SLA metrics look fine but nothing feels fine. This is the classic MSP trick. They hit their contractual SLA targets—99.9% uptime, 4-hour response times, whatever—while your users are still complaining every week. The gap between contractual compliance and actual service quality is where bad MSPs hide.

Every improvement costs extra. Your base contract covers keeping the lights on. Want to upgrade a firewall? Change request. Need a new VLAN? Change request. Migration to a new backup solution? Separate SOW. If every conversation ends with a quote for additional services, your MSP has structured the deal to profit from your growth rather than support it.

Tribal knowledge has left. The good engineers who onboarded your environment have moved on. The people handling your tickets now don’t understand your business context. They’re following runbooks that were written two years ago for an environment that’s changed significantly since then.

The Quantification Exercise

Before you decide to leave, do the maths. I mean actually do it, not just feel angry about the bills.

Add up your total MSP spend: base contract, change requests, project work, overages, and any penalties you’ve paid for early termination of bundled services. Compare that against what it would cost to bring those functions in-house or move to a different provider.

Don’t forget the hidden costs of the current arrangement: internal time spent managing the MSP, productivity lost to slow ticket resolution, opportunity cost of projects that didn’t happen because the MSP couldn’t support them.

I worked through this exercise recently with a mid-market company alongside their consulting practice, and the numbers were stark. The MSP was costing 40% more than an in-house team with selective outsourcing for specialist functions. That’s not a renegotiation conversation—that’s an exit conversation.

When to Try Saving It First

Not every struggling MSP relationship needs to end. Sometimes it needs a reset. Here’s when I’d try fixing it:

The account manager changed. Bad MSP experiences often trace back to a single person leaving. If you had a good relationship before and the current problems started with a personnel change, escalate and demand better account management.

Your environment changed, the contract didn’t. If you’ve grown significantly or changed direction since signing the MSP deal, the contract may simply not reflect what you need anymore. A good MSP will renegotiate scope. A bad one will charge you change request fees.

You’ve never given clear feedback. I’ve seen companies seethe about their MSP for months without ever having a direct conversation about the problems. If you haven’t had an honest service review meeting with specific metrics and expectations, start there.

How to Leave Without Breaking Everything

Exiting an MSP is operationally risky. They have the keys to your environment. If you handle the transition badly, you’ll have a period where nobody fully understands your infrastructure.

Start documentation six months early. Require your MSP to update all runbooks, network diagrams, and configuration documentation as part of their normal service delivery. Don’t announce you’re leaving—just insist on better documentation. If they push back, that tells you everything about the relationship.

Secure your credentials. Before you give notice, ensure you have independent access to every system, account, and tool the MSP manages on your behalf. I’ve seen situations where MSPs held credentials hostage during transitions.

Overlap the transition. Budget for two to three months where you’re paying both the outgoing MSP and whoever’s taking over. This isn’t wasted money—it’s insurance against a gap in coverage.

When choosing what comes next, think carefully about in-house versus another MSP. For core infrastructure—networking, server admin, basic security monitoring—an in-house team often wins if you have enough scale. For specialist functions like security operations or cloud architecture, a focused boutique provider usually beats a generalist MSP.

Making the Call

Fire your MSP when the cost of staying exceeds the cost of leaving. Not just financially—include the cost of your team’s frustration, your users’ lost productivity, and the projects you can’t pursue because your infrastructure partner can’t keep up.

The MSPs I respect are the ones that tell you when you’ve outgrown their service model. The ones I don’t respect are the ones that keep billing you while the relationship deteriorates. Know the difference, and don’t be afraid to make the change when the numbers tell you to.