You know the pattern. You got the call. You had the need. You agreed to the meeting. They walked in with a scope of work, a service level agreement, and promises that sounded exactly like what you wanted to hear.
Your MSP stepped in to be your support, and for a while, it was great. Lots of attention. Their best people on the job. Tickets closed quickly. Phone calls returned.
Then, slowly, over the course of a few months or maybe a year, things started to slip.
Response times stretched. Resolutions that used to take hours now took days. A basic account lockout (the kind of thing that should be fixed in fifteen minutes) sat in queue for 24 hours. You had the conversation with your rep. They promised to address the issues, but suddenly the onus was on you. Keep a log of what's not being resolved. Document who helped you and when. Track the pattern yourself. You're now doing their quality assurance for them.
At some point, you came into the office and made a decision: it's time to make a change.
And then the questions started piling up. How do you make this transition without a gap in support? Will the current MSP play nice with the incoming one, or will they drag their feet and withhold information? What does your contract actually say? Did you lock in for a guaranteed term? Is there a penalty to break the agreement? Do you have access to your backups, or do they reside entirely with the MSP? Do you even have copies of your own network documentation, password vaults, and vendor contacts?
Moving to another MSP can feel like trying to change the tires on a moving car. But it doesn't have to be.
Before you start interviewing new providers, you need to understand what you're walking away from. Most business owners skip this step and end up surprised (and not pleasantly) by what they discover. Pull your current contract. Find the term length and renewal date. Look for auto-renewal clauses and the notice period required to cancel. Check for early termination penalties. Understand the process for retrieving your data, documentation, and credentials at the end of the relationship. And ask yourself: who owns your backups? Where do they physically reside? Can you access them independently, or are you entirely dependent on the MSP to restore them?
If you can't answer these questions, your first step isn't finding a new MSP. It's getting these answers from your current one. In writing.
Once you know what you're dealing with, the transition itself follows a straightforward path. About 30 days before your target cutover date, finalize your new MSP contract and notify your current provider in writing per whatever your contract requires. Request all documentation, credentials, and backup access. Have your incoming MSP review the existing infrastructure and identify gaps before they take over. Two weeks out, confirm you have everything in hand (not promised, in hand), schedule overlapping support if possible, and communicate to your team what's changing and when. On cutover day, the new MSP takes primary responsibility, the old MSP loses access to all systems, and you test critical functions: email, remote access, key applications. A week later, audit all user accounts and permissions, confirm backups are working under new management, and close out any remaining tickets with the old provider.
This isn't complicated. But it does require someone to own it, track it, and hold both sides accountable.
Will your current MSP cooperate? Sometimes. Sometimes not. Some are professional about it. They provide documentation, answer transition questions, and wish you well. Others drag their feet, withhold information, or suddenly discover that your backups are stored in a proprietary format that only they can access (a problem that mysteriously never came up before). You can't control their behavior. But you can document everything, communicate in writing, and escalate early if they start playing games. If they're contractually obligated to provide certain information and they don't, that's a breach. Know your rights.
Here's the thing, though. Switching MSPs solves the immediate problem. But it doesn't answer the bigger question: why did this happen in the first place?
Most MSP relationships fail for the same reason. There's no one on your side evaluating their performance. No one holding them accountable to the SLA. No one asking whether you're getting what you're paying for. You hired them to handle IT, but who's managing them? If you're a M company with 75 employees, you probably don't have a CIO. Maybe you've got an IT manager, maybe just a senior person who inherited tech responsibilities because nobody else wanted them. Either way, there's no one in the room whose job it is to make sure your technology vendors are actually serving your interests.
That's the gap. And it's why so many business owners find themselves in the same position two years later, with a different MSP, having the same conversation about response times and unresolved tickets.
If you've got the time, the expertise, and the bandwidth to manage this transition yourself, the framework above works. But if you're staring at a stack of unanswered questions, a contract you haven't read since you signed it, and a pit in your stomach about what you might find, that's exactly the kind of situation I built my practice to handle. I've been on both sides of these transitions. I've inherited messes left by outgoing vendors and built the processes to prevent them. I've negotiated exits, audited contracts, and managed handoffs that went cleanly because someone was paying attention.
If you need someone to own this for you, no pressure, let's talk.
About the Author
Raphael Savastano is the founder and principal consultant of ROFONIC LLC. With 25+ years in IT, 16 years in leadership, including 8 years as CIO scaling technology for a global manufacturer from M to 0M. He now helps growing companies get executive-level technology and operations leadership without the full-time cost. Want to know where your technology actually stands? Take the Founder's IT Reality Check →
