When to Fire Your MSP: 10 Red Flags (and How to Leave Cleanly)
Yes, we are an MSP publishing the checklist clients use to evaluate MSPs, including us. That is the point. If a provider cannot survive this list, you should know, and we should be held to it too. Here are the ten flags that matter, when the answer is a conversation instead of a firing, and how to exit cleanly.
An honest scorecard beats a sales pitch.
Most businesses that come to us unhappy with their provider cannot name what is actually wrong. Things just feel slow, expensive, and vague. This page turns that feeling into ten checkable items, each one verifiable this week by asking your provider a direct question and watching how they answer.
One rule first: a red flag is a pattern, not a bad day. You are looking for behaviour that repeats after you have raised it. If you are still shopping rather than firing, our guide on how to choose an MSP in Canada covers the same ground from the front end.
10 red flags, and why each one matters.
No monthly reporting
What it looks like. You pay every month and receive nothing back: no ticket summary, no patch status, no backup results. When you ask how things are going, the answer is "all good" with nothing behind it.
Why it matters. A provider with nothing to show usually has nothing to show. You cannot manage a vendor you cannot measure.
Backups never test-restored
What it looks like. Backups "run every night", but nobody can tell you the date of the last successful test restore, or show you evidence that a restored server actually booted.
Why it matters. An untested backup is a hope, not a plan. You find out whether it works on the worst possible day. Restore testing should be scheduled and documented, full stop.
No MFA rollout after a year
What it looks like. Twelve months in and staff still sign in to email with a password alone. MFA is "on the roadmap" or "coming next quarter", indefinitely.
Why it matters. MFA is the cheapest, most effective security control available, and cyber insurers treat it as table stakes. A provider that has not rolled it out in a year is not busy, they are negligent.
Surprise invoices
What it looks like. Line items appear for work you assumed was covered: a password reset billed as a project, "after-hours" charges you never agreed, onboarding a new hire treated as out of scope.
Why it matters. Either the contract is vague or the provider is exploiting the vagueness. Predictable per-user pricing exists so this does not happen. Ours is published openly for that reason.
Tickets vanish, no SLA
What it looks like. You report a problem, hear nothing for days, then have to re-report it. There is no ticket number, no stated response time, and no way to see what is open.
Why it matters. Without an SLA, "we're working on it" can mean anything. A provider that will not commit to response times in writing has told you what their response times are.
They own your documentation and passwords
What it looks like. Admin credentials, network diagrams, and licence records live only in the provider's systems. When you ask for copies, you get delays, excuses, or a claim that it is "proprietary".
Why it matters. This is a hostage situation with extra steps. It makes leaving painful by design, and turns any dispute into a fight over access to your own business. You should hold this information at all times, not just at exit.
Upsells every quarter, roadmap never
What it looks like. Every review meeting ends with a quote for new hardware or a new security product, but nobody has ever shown you a 12 to 24 month plan tied to your business goals and budget.
Why it matters. Selling without planning means the provider is optimising their revenue, not your outcomes. A real roadmap makes spending predictable and lets you say no to things that do not serve the plan.
No named engineer knows your environment
What it looks like. Every ticket starts from zero with a stranger. You explain your setup again and again because nobody at the provider actually knows it, and there is no name you can ask for.
Why it matters. Context is most of the value in managed IT. Without it, every incident takes longer and small problems get misdiagnosed. You are paying retainer prices for break-fix quality.
Security incidents hidden or minimised
What it looks like. You learn about a compromised mailbox weeks later, by accident, or a breach is waved off as "just spam". Nobody mentions your notification obligations under PIPEDA or BC PIPA.
Why it matters. The legal and reputational risk of a breach lands on you, not the provider. A partner who hides incidents is making your compliance decisions for you, without telling you. This flag alone is grounds to leave.
Auto-renewal, long lock-in, exit fees
What it looks like. The contract quietly renews for another three years unless you give notice in a narrow window, and leaving early triggers penalties or "data extraction" fees.
Why it matters. A provider confident in their service does not need to trap you. Long lock-ins with exit fees tell you retention is built on the contract, not the work. Read the renewal clause before you sign, and diarise the notice deadline.
Sometimes the fix is a conversation, not a firing.
Switching providers costs real time and money, so be honest about two common cases. The first is scope creep you never bought. If your agreement covers 20 users and basic helpdesk, and you have since added a warehouse, a second site, and a line-of-business app, slow service may just mean the contract no longer matches the business. The fix is a re-scoped agreement, not a divorce.
The second is unrealistic expectations. No MSP can make a ten-year-old server fast, prevent every phishing click, or deliver enterprise response times at the cheapest tier. If you have declined the roadmap items three years running, some of the pain is a decision you made.
The test: raise the issue in writing, ask for a concrete fix with a date, and see what happens. A good provider will own it and show you the change. Defensiveness, vagueness, or a sales pitch means you have your answer.
How to leave cleanly.
A messy MSP exit can hurt more than a bad MSP. Work through this list before you give notice, and use our full switching MSP checklist for the step-by-step version.
- Data and documentation handover. Request network diagrams, asset lists, configuration notes, vendor contacts, and licence records in an open format. Get exports, not screenshots.
- Licence ownership. Confirm which subscriptions (Microsoft 365, security tools, backup) are in your name versus the provider's. Anything in their name must be transferred or replaced before cutover, or your data goes with them.
- Admin credentials. Obtain global admin for Microsoft 365 and Entra ID, domain registrar and DNS access, firewall and network gear logins, and backup console access. Verify each login yourself, then rotate every password once the old provider is out.
- Overlap period. Have the new provider running monitoring, backup, and helpdesk for two to four weeks before the old one is cut off. Never accept a hard same-day cutover.
- Timing around renewals. Count backwards from the renewal date and the notice window. Missing it by a week can cost a year. Start provider selection three to six months before renewal, and use our MSP RFP template to compare candidates on the same questions.
What "you own it" should mean in your next contract.
Every flag above has a contractual cure, and it fits in one sentence: the client owns everything about their own environment. Your next agreement should state that all licences and subscriptions are registered to your organisation, that admin credentials are held by you and shared with the provider rather than the reverse, that complete documentation is delivered to you and kept current, and that on termination everything is handed over within a fixed number of days at no charge.
Add a defined SLA, monthly reporting as a deliverable, scheduled restore testing with evidence, and a renewal clause that requires your active signature rather than your silence. Any provider who balks at these terms is telling you which red flags they plan to raise later. This is how we write our own agreements, and our pricing page shows per-user costs up front so the surprise-invoice flag never applies.
One more option: sometimes the right answer after firing an MSP is not another MSP. If you are large enough to hire internally, read our breakdown of MSP vs in-house IT first.
Common questions about firing an MSP.
Can my MSP hold my passwords hostage?
They can try, but they are on weak ground. Admin credentials to systems you pay for belong to your organisation, and most contracts do not give the provider ownership of them. If an MSP refuses to hand them over at exit, put the request in writing, reference your contract, and involve a lawyer if needed. A firm written demand resolves most standoffs. The better fix is prevention: your next contract should state that you own all credentials, documentation, and licences from day one.
How much notice do I need to give?
Check your contract. Most MSP agreements require 30 to 90 days written notice, and many auto-renew for a full term if you miss the window. Diarise the notice deadline the day you sign. If you have already missed it, ask for a shorter exit anyway. Some providers will agree rather than serve an unhappy client for another year.
Will switching MSPs cause downtime?
It should not, if done properly. A competent incoming provider runs an overlap period, takes over monitoring and backup before the old provider is cut off, and verifies access to every system first. The risky version is a hard cutover with no overlap and no documentation. That is where outages and locked-out accounts happen.
Is one red flag enough to fire an MSP?
Usually not, with two exceptions. Hiding a security incident, or refusing to hand over your own credentials and documentation, are trust failures rather than service failures, and we would not stay past either one. For everything else, raise it directly, give one clear chance to fix it with a deadline, and judge what actually changes. Multiple flags together, or one flag they refuse to acknowledge, is your answer.
What should I have ready before I tell my MSP we are leaving?
Quietly confirm what you already control: global admin access to Microsoft 365, your domain registrar login, ownership of your backup platform, and copies of any documentation you can export. Choose your new provider first so the overlap starts immediately. Most exits are professional, but you do not want the notice period to be the moment you discover you cannot log in to anything.
Run this checklist against us.
Book a free 30-minute assessment. Bring your current agreement and this list, and we will tell you plainly whether you need a conversation, a re-scope, or a new provider. If staying put is your best move, we will say so.
Get a Free Assessment See our pricing