Changing managed service provider without an outage

The decision to change provider is usually made carefully over months. The transition is then given four weeks, a kick-off meeting and an assumption that the outgoing provider will be helpful.

That assumption is the problem. Not because outgoing providers are obstructive — most are professional about it — but because their team has been reassigned, their knowledgeable people are on other accounts, and their contractual obligation to help ended with the notice period.

Everything below is about doing the work while the information is still available.

Start with what you own

Before any transition planning, establish what is actually yours. This is uncomfortable and it is much more uncomfortable later.

• Domain registrations and DNS. Who is the registrant, who holds the account, and can you log in today? A domain registered in a provider’s name is the single most common and most damaging discovery.
• Tenant and subscription ownership. Microsoft 365, Azure, cloud accounts, and the CSP relationship. Delegated administration is normal; the tenant being owned by the provider is not.
• Licences. Which are yours, which are the provider’s, and which are resold. Some do not transfer, and finding that out at cutover is expensive.
• Certificates and code signing. Including the ones on appliances nobody thinks about until they expire.
• Data in the provider’s tooling. Ticket history, monitoring history, asset registers, documentation. This is your operational record, and it usually lives in a system you lose access to on the last day.

Ask for all of it in writing while you are still a customer in good standing.

Documentation is the deliverable, not a courtesy

Transition-out obligations are in most contracts and are almost never specific enough to be enforceable. “Reasonable assistance” means whatever the outgoing provider decides it means.

What a usable handover pack contains:

• Network diagrams that match reality, including the things added after the last diagram
• Every credential, in a credential store, with the accounts they belong to identified
• Firewall rule sets with the business reason for the non-obvious ones
• Backup configuration, retention settings, and the date of the last successful restore test
• The runbook for anything that is manual, scheduled, or held together by one person’s habit
• A list of every third-party vendor, support contract and renewal date
• Known issues and deferred work, honestly stated

The last one never appears unless it is asked for by name. Ask for it by name.

Run in parallel where you can

Big-bang cutovers fail in the same places every time. Where a service can run in parallel, run it in parallel:

Monitoring first. The incoming provider should be receiving alerts and building a picture weeks before they are responsible for acting on them. This is the cheapest possible way to find out what the environment actually does at 3am.

Service desk second, in overlap. A period where both desks can take a call, with a clear rule about who owns what, beats a hard switch at 5pm on a Friday. Users do not read the transition communications.

Backups third, and verified. The incoming provider’s backup should be running and restore-tested before the outgoing provider’s is decommissioned. Overlapping backup cost for a month is trivial against the alternative.

Privileged access last. Credentials rotate at cutover, not before, and the rotation is a planned activity with a rollback rather than a discovery exercise.

The 90 days after are where the value is

A transition is not finished when responsibility moves. It is finished when the incoming provider knows the environment as well as the outgoing one did, and that takes a quarter.

What should happen in it:

• A documented environment review, produced by the incoming provider from their own inspection rather than restated from the handover pack. The gap between those two documents is the useful information.
• A remediation list with priorities and costs. Every environment has deferred work. A provider who reports none in the first 90 days has not looked.
• Restore testing, actually performed. Not the backup job succeeding — a restore, timed, from a real backup.
• Baseline metrics agreed. Whatever the service levels say, agree what “normal” looks like now, so the first report is measured against reality rather than against the proposal.

What to write into the contract

For the provider you are leaving, and for the one you are joining, because you will leave them eventually too:

• Transition-out assistance specified in days of effort and named deliverables, not “reasonable assistance”
• All documentation to be maintained in a system you own, continuously, not produced at exit
• Data in the provider’s tooling exportable in a usable format on request
• No account, tenant, subscription or domain registered in the provider’s name
• The transition-out obligation surviving termination for any reason, including for cause

The last point matters most, because the transition you have to manage badly is the one that happens after a relationship has broken down.

The short version

The information you need is available while the relationship is good and expensive once it is not. Get the ownership questions answered first, make documentation a contractual deliverable, run services in parallel, and treat the first 90 days as part of the transition rather than the beginning of business as usual.

More on what our managed service actually includes, and the questions worth asking before you sign.