A Clean Break: How to Contract an MSP Transition Without Losing a Quarter

Switching managed service providers is rarely just a procurement exercise. For most UK SMEs it is a continuity event: email, finance systems, production applications, security monitoring and the service desk all depend on institutional knowledge held by the incumbent. The commercial decision may take weeks; the technical handover can take a quarter if it is not specified. The difference between a clean transition and a painful one is usually written into the contract before either party signs.

ResultIT's view is straightforward: treat the handover as a deliverable, not a courtesy. Demand evidence, dates and acceptance criteria. The following framework is designed for SMEs that need to change provider without losing momentum.

Begin With Ownership, Not Migration

The first question is not how data will be moved but who controls it. Confirm that the Microsoft 365 tenant, domain registrar account, DNS zones, SSL certificates, backup repositories, line-of-business applications and any source code or configuration files are held in the client's name. The outgoing provider may administer these items, but it should not own them.

Contractually, require a written schedule of assets and tenancies. It should identify the legal owner, the administrator, the billing relationship and the recovery route for each item. Credentials should sit in a client-controlled password vault, with break-glass access documented and sealed. If the incumbent resells licences through a cloud solution provider agreement, establish early whether those licences transfer, must be re-purchased or need a new CSP relationship. Leaving this to the final week is how SMEs discover that email domains, security tools or backup subscriptions are tied to a reseller rather than to the business.

Put the Handover Schedule in the Contract

A 90-day handover should be a contractual timetable, not a project plan that appears after notice is served. The schedule can be simple: days 1 to 30 for discovery and stabilisation; days 31 to 60 for documentation, access transfer and shadow running; days 61 to 90 for cutover, verification and exit. The incoming provider should name a handover lead and the outgoing provider should name an accountable contact.

The agreement should also set out notice periods, transition fees, knowledge-transfer obligations and the point at which service responsibility changes. Avoid open-ended exit assistance. Specify the number of handover sessions, the format of data returns and the response time for questions during the transition window. Where a service credit or retention is used, tie it to measurable acceptance criteria rather than to goodwill.

Demand Documentation That Can Be Used

Documentation is often delivered as a zip file that nobody can interpret. Require an as-built record that a competent third party could use without calling the incumbent. At minimum, this should include network diagrams, IP addressing, asset registers, application dependencies, administrator guides, backup configurations, disaster recovery runbooks, vendor contacts and an escalation matrix.

The practical test is simple: can the incoming provider resolve a routine issue and restore a test file from backup using only the handover pack? If the answer is no, the documentation is incomplete. Build that test into the acceptance process. It converts a vague promise of knowledge transfer into evidence.

Rotate Credentials and Revoke Access

Access revocation is a security control and a continuity control. Before cutover, compile a credential register covering administrative accounts, service accounts, remote monitoring agents, backup agents, API keys, integration tokens and multi-factor authentication devices. Rotate credentials in a planned sequence so that monitoring, patching and backup jobs do not fail silently. Revoke the outgoing provider's remote access at an agreed point, and keep an audit log of what was changed and when.

This is not a reason to delay the transition; it is a reason to rehearse it. A staged rotation, with rollback positions for critical systems, is safer than a last-minute password change on a Friday afternoon.

Run the 90-Day Parallel Plan

The most reliable transitions include a parallel run. The incoming provider shadows the service desk, reviews alerts and tests recovery procedures while the incumbent remains responsible for live service. Tickets should be visible to both parties. Backups should be verified by the incoming team, not merely accepted from a dashboard.

Set weekly checkpoints with a short list of outcomes: no missed backups, no unpatched endpoints, no unresolved critical alerts, no lost service desk tickets and no unexplained licence gaps. By the final month, the new provider should be leading routine work while the old provider remains available for escalation. The aim is not a dramatic switchover; it is a controlled change of custody.

Exit Clauses That Protect the Business

The exit clause should survive the relationship. Require the return of client data in a usable format, a deletion certificate for copies held by the outgoing provider, and a defined period of post-exit support. Check that notice periods align with contract renewal dates and that transition charges are published rather than negotiated under pressure.

A Practical Acceptance Checklist

Before signing with any provider, ask for:

• A named handover lead and a dated 90-day plan.
• Proof of client ownership for domains, tenants, licences and backups.
• An asset and credential register in a client-controlled vault.
• As-built documentation tested by a third party.
• A credential rotation and access revocation schedule.
• A parallel-run period with joint service desk visibility.
• Defined data return, deletion and post-exit support terms.

A provider that resists these requirements before winning the contract is unlikely to volunteer them after losing it. The 90-day handover is not bureaucracy; it is the mechanism that keeps a commercial change from becoming an operational setback.