How to Switch Managed Services Provider | blueAPACHE

Switching managed services provider is the part of the relationship organisations think about least and fear most, and the fear is usually about the wrong thing. The risk is rarely the new provider's competence. It is the loss of knowledge that lives in the outgoing provider's heads and ticketing system, and the discovery that your contract did not secure a clean exit. This page sets out a practical sequence.

Before you give notice

1. Read your exit provisions. Notice period, minimum term status, disengagement services, data return obligations, and any early termination charges. Do this before you start a procurement, because it determines your timeline and your leverage.

2. Establish what you actually own. Specifically:

• Do you hold administrative credentials for your own systems, or does the provider?
• Who owns the licences — you, or the provider on your behalf via a subscription that ends with the contract?
• Where does your documentation live, and can you export it?
• Whose tenant are your monitoring, backup and endpoint management tools in?
• Do you have a copy of your own backups outside the provider's platform?

Any answer that is not "us" is a dependency to plan around. Licences held under a provider's agreement and monitoring in a provider's tenant are entirely normal — they just need to be identified early, because they become migration work.

3. Extract documentation while the relationship is still good. Network diagrams, asset inventory, runbooks, escalation contacts, vendor account details, circuit IDs. Request it as part of routine service review rather than as a departure signal.

4. Do not give notice before you have a signed replacement. A gap between providers on an estate you do not operate yourself is the one scenario genuinely worth fearing.

Expect friction, and plan for it

Some incumbents transition professionally. Some do not, and the failure modes are predictable: documentation that arrives late or incomplete, knowledge-transfer sessions that get rescheduled, key staff suddenly unavailable, credentials handed over in pieces.

None of this is usually malicious. An outgoing provider has no commercial incentive and a departing account is deprioritised naturally.

So the question to ask every prospective provider is: how do you rebuild environment knowledge when the incumbent does not cooperate? A provider with a real answer — independent discovery tooling, a methodology for reconstructing an estate from what they can observe rather than from what they are told — has done this before. A provider who assumes cooperation has not, and their timeline will slip.

What transition-in should include

Transition-in is real work and should be a defined deliverable, not an assumption:

• Discovery and documentation of the estate as it actually is
• Tooling deployment — monitoring, patching, endpoint management, service desk
• Knowledge transfer from the incumbent where available, and independent discovery where not
• Service desk establishment — how your people raise issues, and communication of that change
• Credential and licence transfer
• A defined go-live with a period of heightened support

Ask whether this is contractually defined work with a deliverable, or best endeavours. The distinction shows up in month two.

blueAPACHE treats transition-in as contractually defined work rather than best endeavours, and the front-loaded nature of it is the stated reasoning behind the 36-month default minimum term — the investment is amortised across the initial term.

→ Onboarding and Transition-In — What Switching MSP Actually Involves → Why Managed Services Contracts Have Minimum Terms

A realistic sequence

1. Review exit provisions and establish ownership of credentials, licences, tooling and data
2. Extract documentation
3. Define scope, run the procurement, select a provider
4. Sign, with transition-in scoped as a deliverable
5. Give notice, timed so transition overlaps the notice period rather than following it
6. Run discovery and tooling deployment in parallel with the incumbent still operating
7. Cut over service desk and monitoring
8. Heightened support period
9. Formal closure with the incumbent — final data return, credential revocation, licence reassignment

The critical design point is step 6: overlap, do not sequence. Transition should happen while the old provider is still contractually obliged to keep the lights on. A cutover on the day the old contract ends removes your fallback.

The mistakes that cause most of the pain

• Giving notice first, then starting procurement. It inverts your leverage and compresses transition into the notice period.
• Assuming the incumbent will help. Plan for the case where they do not.
• Not identifying licence and tenancy dependencies until cutover week.
• Underestimating your own team's time. Transitions need your people for discovery, decisions and validation. This is the most common cause of slippage and it sits on your side.
• Cutting over during a peak period. Choose the calendar deliberately.
• Skipping the heightened support period to save money.

When not to switch

If the problem is a specific person or a specific unresolved issue, escalate formally within the existing relationship first — a documented escalation with a remediation plan sometimes fixes what a procurement process would only replicate elsewhere.

If your own estate is the problem — undocumented, unpatched, unowned internally — a new provider inherits that and the first year will be remediation regardless of who you choose. Worth knowing before you attribute the outcome to the switch.

And if you are mid-way through a major business change, the sequencing question is real. Switching provider during an ERP implementation is possible and rarely advisable.

→ Due Diligence Questions for IT Provider Procurement