Transfer in five gates
| Gate | Deliverable | Hold condition |
|---|---|---|
| Inventory | Clients, assets, users, coverage and exclusions | Counts or tenant mapping disagree |
| Knowledge | Approved runbooks, owners and escalation paths | Missing instructions for a critical service |
| Shadow operation | Both teams observe the same cases | Actions or ticket history cannot be reconciled |
| Limited cutover | One bounded queue or client group transferred | Buyer cannot restore retained coverage |
| Accepted operation | Outcomes reviewed and residual risks assigned | Blocking pilot failure remains unresolved |
An inventory should identify unsupported assets as well as enrolled ones. The client list alone does not establish the scope: record business-critical applications, vendor dependencies, maintenance windows and special approval rules. Reconcile the billable inventory separately from the operational inventory so the first invoice does not define the service by accident.
Make knowledge actionable
For each runbook, record the signal, checks, permitted action, approval requirement, stop condition and rollback owner. Assign a version and reviewer. Ask the external team to explain one procedure back to the buyer using a test case; a document upload without a demonstrated understanding is incomplete transfer.
During shadow operation, select one active actor and one observer. Two teams making simultaneous fixes can hide responsibility or introduce conflicting changes. Record who will communicate with the customer and which system is the incident record. Resolve differences in tenant names, severity and ticket states before live cutover.
Cut over one obligation
Illustrative scope: transfer only the approved overnight workstation queue for a small consenting client group, retaining infrastructure changes and security containment internally. Record the exact start time and timezone, incoming owner, fallback phone route and how unfinished tickets are accepted. This example is not a proposed universal client rollout size.
Rollback triggers can include a tenant mismatch, inability to contact the escalation owner, missing permitted-action controls or an unacceptable backlog. Agree who makes that decision, how new work returns to the MSP and how the provider stops actions. Test independent access revocation before the buyer relies on it during an incident.
Verify after acceptance
Review the first invoice against enrolled scope, sample ticket quality and reconcile the retained workload. Keep open items with owners and due dates. A successful cutover does not establish permanent performance; changes to staff, tools and client inventory need renewed verification. Prepare an exit plan before removing the former coverage. Use the NOC pilot and desk pilot for service-specific acceptance evidence.