Checklist
The MSP switching checklist: changing providers without losing continuity.
This checklist is for leaders and IT managers who are changing managed service providers and want the handoff to leave no gap in support, security, or access. It complements the MSP Buyer's Guide, which covers choosing a provider; this checklist covers changing providers without losing operational continuity.
Part 1 of 5
Before you give notice.
- Read the termination, notice, and renewal terms in your current agreement. A missed notice window or an automatic renewal can extend the old agreement and leave you paying two providers while the change takes place.
- Have counsel review the exit, data return, and transition-assistance clauses. Agreements differ on what an outgoing provider owes you and by when, and unclear language is easier to resolve before notice than after it.
- List every system, account, and service the current provider manages for you. Anything missing from the list is usually found after cutover, when a backup job, license, or monitoring task quietly stops being managed.
- Name one internal owner for the transition, with authority to approve changes. Without a single decision-maker, approvals stall between departments, and the cutover is either delayed or rushed to recover the lost time.
Part 2 of 5
Secure your documentation and credentials.
- Request an export of network diagrams, configuration records, and runbooks in a usable format. Documentation locked in the old provider's portal becomes unreachable at termination, and rebuilding it by inspection slows the new provider's work and invites errors.
- Confirm your organization holds administrator credentials for Microsoft 365, domains, firewalls, and cloud accounts. Accounts registered to the provider rather than to your organization can leave you unable to change or recover a service when the relationship ends.
- Record domain registrations, DNS hosting, certificates, and their renewal dates. A lapsed domain or an expired certificate tends to surface weeks after a handoff, when no one remembers who was responsible for renewals.
- Collect licenses, warranties, and third-party support contracts held in the provider's name. Licenses and warranties bought through the old provider may not transfer automatically, and the gap appears as an expired subscription or a declined support request.
Part 3 of 5
Protect security and backups during the handoff.
- Keep endpoint protection and monitoring active until the new provider's tools are verified. Removing the old agents before the new ones report in leaves devices unmonitored, and an incident during that window has no one watching.
- Confirm where backups are stored, who owns the storage, and how to restore from it. Backups held in the old provider's account can become unreachable at termination, and a backup that has not been restored is an assumption, not a recovery plan.
- Run a test restore before the outgoing provider's access ends. A restore test shows whether the backups are usable while the people who built them are still available to answer questions.
- Rotate shared passwords, service accounts, and remote access credentials after the handoff. Credentials the outgoing provider knew stay valid until they are changed, which leaves standing access to your environment that no one is accountable for.
Part 4 of 5
Plan the cutover and the support path.
- Agree on a written cutover schedule that avoids month-end, payroll, and other busy periods. Changes made during a busy period turn minor issues into business disruptions, and staff tend to blame the new provider for them.
- Tell staff in advance who to call, which number or portal to use, and when. If requests keep going to the old provider after cutover, they are lost, and staff lose confidence in the new support path.
- Move phone routing, email contacts, and ticketing only after the new Service Desk confirms readiness. Redirecting support channels before the new team is ready creates a period when requests arrive and nobody owns them.
- Document line-of-business applications and the outside vendors who support each one. Application vendors often know the outgoing provider by name, and without an introduction, support requests for key systems can stall.
Part 5 of 5
After the change.
- Review early tickets with the new provider and correct recurring issues quickly. Patterns in the first weeks show what discovery missed, and recurring issues left alone become the normal state of the environment.
- Obtain written confirmation that the former provider has removed its access and returned your data. Without confirmation, remote access tools and stored copies of your data can remain in place with no one accountable for them.
- Hold a review with the new provider covering inventory, risks, and a 12-month roadmap. A handoff records the environment as it stands; a review decides what to improve and in what order, so the change leads somewhere.
- Update insurance, vendor, and audit records with the new provider's details. Questionnaires, contracts, and audit files often name the managed provider, and outdated entries cause confusion at the next review.
Questions
What leaders ask about changing providers.
How long does a change of managed service provider take?
The timeline depends on the size of the organization, the number of locations, the quality of existing documentation, and the notice terms in the current agreement. A well-planned change is staged: discovery, stabilization, and then cutover on a schedule you approve. Ask any prospective provider for a written plan with dates before you sign.
Will our staff lose support during the change?
A planned transition keeps the current provider's coverage in place until the new Service Desk is confirmed ready, and staff are told in advance whom to call. Gaps usually come from unplanned handoffs, such as access removed too early or tickets still routed to the old team, which is why the cutover is scheduled and verified.
What if our current provider is slow to hand over documentation?
Start with what your organization already owns: administrator access to Microsoft 365, domain registrations, and cloud accounts. Review the exit and data return clauses with counsel, and make requests in writing with dates. A new provider can also rebuild documentation through discovery, which takes longer but does not depend on cooperation.
Should we notify the current provider before choosing a new one?
Generally not until you have read the notice terms and selected a provider. Notice can start the clock on the agreement and change how the outgoing team engages. Once you decide, give notice as the agreement specifies, in writing, and keep the outgoing provider's support in place through the cutover.
Can a new provider work alongside our internal IT staff?
Yes. Many organizations keep an internal IT person for priorities and local knowledge, and add a provider for the Service Desk, security operations, and project capacity. The transition plan should state which tasks each side owns, so that nothing is assumed by both sides or by neither.
What should we ask a new provider about the transition itself?
Ask for a written onboarding plan, the named team, a schedule for discovery and cutover, and a list of what the provider needs from you. Also ask who owns the documentation once the work is done. The MSP Buyer's Guide covers the broader questions for comparing providers.
Next step
Talk through a transition plan for your environment.
If you are considering a change of provider, we are glad to talk through a transition plan for your environment, on a timeline that fits your agreement and your team.
- No obligation.
- Prefer to talk? Call 844.884.8040.
Ready to make your technology work harder for your business?
Schedule a complimentary 30-minute conversation with our team.
The form is unavailable right now. Prefer to talk? Call 844.884.8040.