Your MSP Isn’t Working: 9 Signs It’s Time to Switch

Consider an illustrative 120-person company that has used the same managed service provider for 4 years. Nothing has ever gone catastrophically wrong, but the CFO notices that a laptop request took 9 days, the office manager keeps explaining the same printer fault to a new technician each month, and nobody can say whether the backups have ever been restored. The contract renews in 3 months. Everyone suspects the relationship has gone stale, yet nobody can prove it, and switching feels risky enough that the default is to sign again.

This article lays out 9 signs that an MSP relationship has stopped working, how to confirm each with evidence, and how to leave without breaking anything if the evidence says leave. It draws on CISA’s voluntary performance goals for security baselines, an MSP’s published offboarding guidance for the transition, and a vendor’s service-desk targets for response metrics. Those vendor figures are unsourced, so treat them as starting points. Confirm contract and legal questions with counsel before you act.

TL;DR

• Judge the MSP on evidence, not irritation. Pull 90 days of ticket data, a security baseline check and a restore test before you decide anything. Annoyance is real, but contract disputes and replacement decisions go better when you can point to numbers and documents rather than a general sense that service has slipped. Write the findings down.
• The costliest signs are the invisible ones. Slow tickets are obvious. Untested backups, admin accounts you don’t control and missing multifactor coverage stay hidden until an incident, and CISA’s performance goals treat those basics as a minimum, not an extra. Verify them yourself or through an independent party.
• Start the exit plan early. An MSP’s guidance suggests beginning at least 90 days before renewal, since notice windows commonly run 30, 60 or 90 days. Control your credentials and documentation first, keep an overlap period, and have counsel read the termination terms. Treat the dates as firm until counsel says otherwise.

What “not working” means before you count the signs

An MSP relationship isn’t working when the outcomes you’re paying for no longer arrive, and you can show that. That sounds obvious, but many switching decisions start from a single bad week, a personality clash or a competitor’s pitch. Those are triggers, not evidence. A better starting point is to write down what you bought: response times, coverage hours, security duties, reporting, planning meetings and recovery commitments. Then compare the agreement to what actually happened over the past 90 days.

A simple scorecard keeps the review honest. Rate each of the 9 signs below from 0 to 2, where 0 means no problem, 1 means a partial problem and 2 means a clear failure with evidence. That gives a maximum of 18. The threshold is my own illustrative rule: a total of 9 or higher, or any 2 on the security and access signs, justifies opening a serious replacement conversation. Adjust the cutoff to your risk tolerance, and share the scorecard with the MSP first.

Before you start, collect the contract, the service level schedule, the last 12 months of invoices, ticket exports and any reports the MSP has sent. If the MSP can’t or won’t provide ticket exports, that’s already a finding. Ask in writing, set a deadline and keep the reply. A provider that handles this request promptly and politely is often a partner worth fixing the relationship with, while a provider that stalls tells you something about how it treats your data.

Sign 1: tickets are slow and nobody owns them

• Response times drift well past the agreement. Compare the contract’s stated response and resolution targets with your actual ticket timestamps. If urgent tickets routinely wait hours and routine ones wait days, the agreement is decorative. Export the data yourself from the ticketing portal if you can, and calculate the median and the slowest 10 percent, since averages hide the painful outliers that employees remember and complain about. Keep the raw export as evidence for later.
• Tickets bounce between technicians. A vendor’s published guidance (Mizo, which sells service desk automation, so treat the figures as unsourced) says first-touch resolution of 60 to 75 percent is achievable for a well-run desk and that anything below 50 percent suggests systemic problems. On an illustrative 300 tickets a month, 60 percent leaves 120 needing follow-up, and 50 percent leaves 150. Ask for a count of tickets reassigned more than once, since that number reveals how much routing effort is wasted.
• Staff have stopped filing tickets. When employees text the single technician they know or fix problems themselves, ticket counts fall and the MSP’s dashboard looks healthy. Ask department heads how they actually get help. The gap between tickets filed and problems experienced is a reliable signal that trust is gone, and it means any metric the MSP reports understates the real friction. Run a short anonymous survey if people are reluctant to say it aloud.
• The cost of delay is real. As an illustration, a 120-person company with 120 tickets a month, where a quarter blocks someone’s work and each waits an extra 3 hours at a loaded cost of $40 an hour, loses $3,600 a month, or $43,200 a year. Those inputs are assumptions. Replace them with your own ticket volume and wage data before you put the number in front of anyone. Show the assumptions beside the result in any memo.

Sign 2: the same problems keep coming back

A recurring ticket means the first fix addressed the symptom, and the cause is still there. Good providers separate incidents from problems: an incident is restored quickly, while a problem record tracks the underlying cause until it’s eliminated. Ask your MSP whether it maintains problem records, how often it reviews them and who owns them. If the answer is vague, the technicians are working a queue rather than improving your environment.

Ask for a list of the 10 most frequent ticket categories from the last quarter and what has changed to reduce each. A healthy provider will show declining volume in the categories it has worked on. An unhealthy provider will show the same categories at the same volume, because closing tickets is the metric it’s rewarded for. If the list looks the same every quarter, you’re paying to repeat the same work indefinitely.

Sign 3: you can’t see reporting that means anything

A monthly report that counts tickets isn’t reporting. Ticket totals say how busy the desk was, not whether your environment improved. A useful report shows response and resolution times against the agreement, first-touch resolution, reopen rate, patch compliance, backup success and restore tests, security alerts and their disposition, and open risks with owners. If your report is a single page of green icons, ask what red would look like and when it last appeared.

Reports should come with a conversation. The best MSPs walk you through the numbers, explain misses and propose changes. If you receive a PDF with no meeting, or a meeting that covers only new products, the relationship is transactional. Insist on a quarterly review with a named account lead, a written agenda and notes. Reviews should end with decisions and owners, not with an agreement that things are generally fine.

You should be able to verify any claim independently. Ask for read-only access to the ticketing system, the patch tool and the backup console. Providers confident in their work grant it readily. Those who refuse often cite security or complexity, and those reasons can be legitimate for administrative rights but rarely for read-only views of your own data. When access is denied, ask for scheduled exports in a format you can open without their software.

Sign 4: the security basics can’t be proven

CISA’s Cross-Sector Cybersecurity Performance Goals describe themselves as a minimum set of voluntary practices, written with small and medium organizations in mind. They call for multifactor authentication, preferring phishing-resistant methods, starting with privileged administrative accounts. They call for backing up systems needed for operations, storing backups separately and testing them at least once a year. They ask for an asset inventory updated at least monthly and a minimum password length of 15 characters where feasible. Your MSP should be able to show you where you stand against each.

Turn those goals into a short audit. Ask for a list of administrative accounts and their multifactor status, the date of your last backup restore test and who ran it, the current asset inventory with its last update, the password policy settings and a confirmation that critical logs are collected and stored centrally. CISA’s goals also say to change default passwords before devices join a network. Each question has a factual answer. If the MSP answers with reassurance rather than evidence, mark the sign as at least a 1.

Pay attention to what the MSP does when the audit finds gaps. A good provider thanks you, opens projects and schedules fixes. A defensive provider explains why the gap doesn’t matter or implies that you’re second-guessing them. CISA’s goals also say contracts should require vendors to notify you of security incidents within a risk-informed timeframe, so check whether your agreement includes that language. If it doesn’t, you’ve got a contractual gap whether or not you’ve got a technical gap.

Sign 5: nobody is planning your technology

A managed provider should act as a planning partner as well as a repair service. Many include a virtual CIO or account lead role for exactly this reason, and if yours promised it, check whether the meetings have actually happened. Ask when the last roadmap review took place and what decisions came out of it. If the honest answer is “a year ago” or “never,” then you’re buying maintenance while carrying the planning risk yourself.

Surprises are the clearest cost of poor planning. If you’ve faced an unexpected server replacement, an emergency license purchase or an unsupported system that failed during a busy week, ask whether the provider knew about the end-of-life date and when. A provider that tracked it and warned you has done its job, even if the news was unwelcome. A provider that learned about it at the same time you did hasn’t.

Sign 6: you don’t control your own accounts

• Domain, tenant and registrar accounts are in the MSP’s name. An outgoing provider’s guidance (Sourcepass, an MSP, so it’s marketing as well as advice) says to confirm your organization controls the domain and DNS, Microsoft 365 admin accounts, backups, firewalls and cloud portals. If your company can’t log in as an owner to each of those, you don’t fully own your environment. Fix this even if you plan to stay.
• Credentials live only in the MSP’s tools. If the only copy of your administrative passwords sits in the provider’s password manager, a dispute or a breach at the provider can lock you out. Ask for a break-glass set of credentials stored under your control, with multifactor protection and a documented process for rotation. The MSP should support this, because it protects them as much as it protects you. Review that arrangement at every quarterly meeting.
• Documentation is thin or unavailable. The same guidance lists network diagrams, device inventories, security configurations, backup schedules, license details and ticket history as items to request. If those documents don’t exist, a new provider will spend weeks rediscovering your environment, and you’ll pay for it. If they exist but can’t be shared, ask why, and get the answer in writing. Ask for a dated inventory of what exists and a plan for creating the rest within a fixed number of weeks.
• Hardware and licenses are ambiguous. Review who owns the firewalls, switches and software licenses and who holds the vendor accounts. Some agreements treat equipment or configurations as the provider’s property, which complicates departure. Have counsel read the ownership and termination language, and confirm in writing which assets you retain if the agreement ends, including configuration backups you can hand to a replacement. Do this before any dispute begins, because requests made mid-dispute draw defensive answers.

Sign 7: backups exist, but recovery is unproven

A green backup report proves a job ran, not that you can recover. CISA’s goal says to test backups at least once a year and store them separately from the source systems. Ask for the date of your last restore test, what was restored, how long it took and who verified the data. If the answer is “we monitor the jobs,” then recovery is an assumption. Schedule a test within the next 30 days and observe it.

Restoring time matters as much as restoring success. A restore that works but takes 3 days may break the business. Ask your MSP to state recovery time objectives for your critical systems and compare them with test results. If the objectives were never defined, define them now with department heads. The numbers don’t need to be precise to be useful, and they give both sides a standard to meet and measure.

Ask about ransomware readiness specifically. Find out whether backups are immutable or isolated from your administrative credentials, how long they’re retained and who can delete them. An attacker with stolen domain credentials will go after the backup system early, as many incident reports describe. If the same account that manages your servers can also delete your backups, the architecture needs work. Raise it in writing and ask for a remediation date.

Sign 8: the people keep changing

Turnover happens at every provider, so the question is how well the MSP absorbs it. Strong providers keep documentation current, assign a primary and a backup technician to each client and brief new staff before they touch your environment. Weak ones depend on individual memory, and when that person leaves the knowledge leaves with them. Ask how many different technicians handled your tickets last quarter, and how the MSP transfers knowledge.

Pay attention to your own staff’s reaction. If employees ask for a specific technician by name, that technician is carrying the relationship and the documentation in his or her head, which is a single point of failure for both you and the MSP. If they dread calling the help desk because it means starting from scratch, the process has failed regardless of the technicians’ skill. A good provider fixes both with documentation and continuity.

Sign 9: the invoice and the contract surprise you

Billing confusion is a quiet sign of trouble. Review your last 12 invoices against the agreement. Look for charges outside the stated scope, project work billed without a quote, license markups you didn’t approve and per-device counts that don’t match your inventory. Ask for an itemized breakdown and a reconciliation of devices and users. A transparent provider produces it within days. A provider that can’t explain its own invoice probably can’t explain its own processes either.

Scope disputes are the second pattern. “That’s not included” is fair when the agreement says so, and corrosive when the agreement is vague. Read the service schedule for covered systems, covered hours, included projects and exclusions. List the last 5 times you were told something was out of scope, and check whether the agreement supports it. If you were routinely billed for tasks the contract implies are covered, either the agreement or the relationship needs rewriting.

Then read the termination terms. The offboarding guidance from Sourcepass warns that missing the notice window can renew the agreement automatically, that notice commonly falls 30, 60 or 90 days before renewal, and that early termination may trigger fees. If your contract renews on January 1 with 90 days’ notice, the deadline is October 3, which is already past today’s date. Counsel should confirm what the contract actually says and what options remain, such as renegotiating the term.

Fix it or leave it: questions to ask first

• Have you told the MSP what’s wrong, in writing? Send a concise letter listing the evidence behind each sign, the outcome you expect and a date for a response. Many problems come from unspoken expectations, and a documented request gives the provider a fair chance. It also creates a record if you later need to argue that the provider failed to meet obligations. Keep the tone factual and the request specific, so it reads as a fair opportunity.
• Does the MSP present a credible improvement plan? Look for specific changes, named owners and dates, such as a staffing adjustment, a new reporting package, a restore test scheduled or a root-cause review of recurring tickets. Vague apologies and discounts aren’t a plan. Give the plan 60 days and measure it against the same metrics you used to find the problem. Write down the metrics you’ll check on day 60 and share them with the provider.
• Is the problem fixable at their scale? Some mismatches are structural. A provider built for 20-person offices may struggle with 150 users and compliance duties, while a large provider may treat a small client as low priority. If the issue is fit rather than effort, a plan won’t solve it. Ask the provider honestly whether your needs are inside its sweet spot. Fit problems are nobody’s fault, but they still justify a planned and orderly change.
• What does staying cost, and what does leaving cost? Estimate the annual cost of the problems using your own assumptions, like the $43,200 delay example earlier, and compare it with the upfront cost of transition, parallel running and any early termination fees. Include the risk of the unproven items, such as untested backups. The comparison won’t be exact, but it often clarifies the decision. Present both numbers to leadership with the assumptions clearly visible.

How an orderly exit works

Secure access before you announce anything. Confirm you hold owner-level access to your domain registrar, DNS, Microsoft 365 or Google tenant, firewalls, backup consoles and cloud portals. Store credentials in a password manager your company controls and share them with the new provider through a secure method. Sourcepass lists this as an early step for good reason: if the relationship turns sour, access becomes bargaining power. Do it quietly and early.

Collect documentation and ticket history. Request network diagrams, device inventories, security configurations, backup schedules, license details and the ticket history. Ask for a written handover plan and a named contact for the transition. Agree on a format you can read without the MSP’s tools. Where documents don’t exist, ask the new provider to build them during onboarding and budget for that work, since discovery of an undocumented environment takes real time.

Run an overlap and a final audit. Sourcepass recommends keeping the outgoing MSP active until the new provider has deployed tools and verified stability, with a short overlap, though it doesn’t specify a length. After cutover, remove the old vendor’s agents and administrative privileges, confirm asset ownership, resolve open tickets and settle the final invoice. Record what you learned in an internal note so the next review starts from facts rather than memory.

A timeline from decision to cutover

The guidance cited here suggests starting at least 90 days before renewal and says offboarding commonly takes 30 to 60 days, though that figure is unsourced. If you start on October 14, 30 to 60 days from now lands between November 13 and December 13. Those dates are only illustrative. The real calendar depends on notice terms, project complexity and how cleanly your documentation and access are set up. Build slack in, and avoid cutting over during your busiest season.

Choosing the next provider

Use what you learned from the failure to set the selection criteria. If the main sign was weak reporting, require a sample report and a live walk-through of the dashboards. If it was security evidence, ask the candidate to show how it would document multifactor coverage, restore tests and asset inventory against the CISA goals. If it was staff churn, ask about technician tenure, documentation practices and how clients are assigned. Make each candidate demonstrate the thing your last provider failed to deliver.

Ask for references of similar size and industry, and call them. Ask what happened during the first 90 days, how the provider handled a bad week and whether they would sign again. Request the standard agreement early, so counsel can review the term, notice period, termination fees, data return, ownership of assets and incident notification clauses. CISA’s goals suggest requiring vendors to notify you of incidents within a risk-informed timeframe, which is a reasonable clause to ask for.

Negotiate the first agreement with the exit in mind. Ask for a shorter initial term or a termination-for-cause right tied to measurable service failures, a clear statement that you own your accounts and documentation, a defined transition assistance obligation at a stated rate and read-only reporting access. Providers who refuse every item on this list are telling you how they plan to handle a disagreement. Providers who accept them tend to be confident in their own work, which is the quality you want.

Mistakes people make when they switch

• Leaving before securing access. Announcing a decision before you control the registrar, tenant and backup accounts hands bargaining power to the party you’re leaving. Verify access quietly first, and rotate shared credentials at cutover. If you discover a gap, address it in writing and ask counsel how to proceed if the provider resists. This is the mistake that turns a routine change into an emergency. Do the technical checks first and have the difficult conversation second.
• Skipping the overlap. A hard cutover risks gaps in monitoring and remote access, particularly if the new provider’s tools take days to deploy. Keep the old provider’s monitoring and support active until the new provider confirms stability. The extra weeks cost money, but a day without email or backup coverage usually costs more than the overlap does. Budget for it in advance, and ask both providers to agree in writing on who is responsible for which systems each week.
• Repeating the same selection process. Companies often choose the replacement with the same slide deck comparison that produced the original, then end up with the same problems under a new logo. Change the process. Test candidates on the failures you found, ask for evidence and talk to references. A provider that looked best in a pitch may not be the firm that survives a hard question. Score candidates against written criteria so that personal rapport doesn’t decide the outcome.
• Ignoring your own part. Some MSP failures are shared failures. If your staff bypass the ticket system, approvals take weeks or nobody on your side owns the relationship, a new provider will inherit the same friction. Name an internal owner, set a quarterly review and agree on how requests flow. A good provider can’t fix an environment where nobody responds to their questions. Document that internal process on a single page that everyone can follow and revisit.

FAQs

How do I know if my MSP is really failing or I’m just frustrated?

 Collect evidence over 90 days. Export tickets and measure response and resolution times against the agreement, check reopen rates, ask for backup restore proof and review your admin account access. Score the 9 signs from 0 to 2 and compare the total with your own threshold. If the facts support the frustration, you’ve got grounds to act. If they don’t, the issue may be communication or expectations, which a conversation can fix.

How much notice do I need to give before leaving?

 It depends entirely on your contract. An MSP’s guidance says notice commonly falls 30, 60 or 90 days before renewal, that some contracts renew on the signing anniversary rather than year-end, and that missing the window can auto-renew the agreement. Read your own agreement and have counsel confirm the dates, any early termination fees and your options if the window has already passed. Calendar the dates the day you finish reading, and set reminders well ahead of each date.

What should I do first if I plan to switch? 

Secure access. Confirm you hold owner-level control of your domain, DNS, tenant, firewalls, backups and cloud portals, and store credentials in a system your company controls. Then gather documentation and ticket history. Do this before announcing a decision, because access is the biggest practical risk in a transition. Have counsel review the termination language before you send any notice. Write down who currently holds each credential and where the recovery methods are stored, so nothing depends on memory.

How long does switching MSPs take?

 An MSP’s guidance estimates offboarding at 30 to 60 days, depending on contract terms, network complexity and data transfer needs, though it gives no source. Allow more time if documentation is thin or your environment spans many locations. Starting at least 90 days before renewal, as that guidance suggests, gives room for selection, notice and overlap, plus a final audit without rushing the cutover. Treat the range as a planning input rather than a promise from any provider.

What security basics should any MSP be able to prove?

 CISA’s voluntary performance goals are a good yardstick: multifactor authentication on all accounts starting with administrators, backups stored separately and tested at least annually, an asset inventory updated at least monthly, passwords of at least 15 characters where feasible, and centrally stored logs. Ask your MSP to show evidence for each, as well as assurances, and put the answers in your quarterly review. Keep the evidence in a folder you control so each review starts from the previous review.

What does a good service desk actually deliver?

 It resolves most issues on the first contact, assigns tickets correctly, responds within the agreed times and shows declining volume in recurring categories. A vendor in this space suggests a first-touch resolution of 60 to 75 percent for well-organized desks, but that figure is unsourced, so compare it with your own baseline. The better test is whether employees use the desk willingly and problems stay fixed. Ask your MSP to show those trends for the last 4 quarters.

Should I tell my MSP I’m unhappy before I leave? 

Usually yes, in writing, with evidence and a date for a response. A documented concern gives the provider a fair chance to improve, and it creates a record if the dispute becomes formal. Secure your access and documentation first. If the provider responds with a credible plan, give it a defined period and measure progress. If not, you’ve lost nothing by asking. Keep copies of every exchange in a folder you control.

Can I get out of a contract early? 

Possibly, but it depends on the wording. Some agreements allow termination for cause tied to missed service levels, while others charge early termination fees or auto-renew. A provider’s marketing guidance can’t tell you what your contract permits. Ask counsel to read the term, notice and termination clauses, plus ownership terms, and confirm what you retain, including documentation and configuration backups, before you send any notice. Don’t stop paying invoices before counsel has advised you on the consequences.