Switching IT providers is a transfer of operating responsibility, not just the installation of new support software. Your business needs access, documentation, protection, and a clear place to request help throughout the handoff.
Use milestones to judge readiness. A date is useful for coordination, but should not override unresolved access or recovery risks. Notice periods, licensing commitments, missing records, site work, and application dependencies can all change the schedule.
Name three transition owners
Assign a business decision-maker, an outgoing-provider contact, and an incoming technical lead. Keep one shared issue register with an owner, next action, due date, and impact for every unresolved item.
The business approves the transition and maintains ownership of its accounts. The outgoing provider supplies agreed records and access transfers. The incoming provider validates that the handoff works. Contract disputes and commercial obligations should be handled by the authorized business representatives rather than improvised by technicians.
Complete the handoff inventory
Transfer sensitive material through an agreed secure process, not ordinary email or a public contact form.
Scroll horizontally to compare all columns.
| Area | What to obtain or verify | Acceptance evidence |
|---|---|---|
| Identity and tenant ownership | Business-controlled administrative access, roles, recovery contacts | Authorized access tested; emergency-access process verified |
| Domains and DNS | Registrar, DNS hosting, certificates, renewal ownership | Account control and current zone/configuration records |
| Devices and infrastructure | Inventory, locations, diagrams, management systems | Asset sample reconciled against physical/current records |
| Microsoft and other subscriptions | Licenses, resellers, billing, renewal terms | Transfer/dependency plan with no assumed cancellation |
| Backup and recovery | Covered workloads, storage, keys, retention, recovery procedure | Representative restore validated by an authorized owner |
| Security tooling | Product coverage, policy ownership, active alerts, exclusions | Replacement coverage and escalation tested before removal |
| Applications and vendors | Support contacts, integrations, service accounts, maintenance windows | Critical workflows and vendor paths tested |
| Open work | Incidents, risks, projects, exceptions, scheduled changes | Each item accepted by a named incoming owner |
Do not assume a license, backup repository, or management account is transferable. Establish the supported transfer path and commercial permission before removing the old service.
Use a milestone-based timeline
This is an illustrative planning sequence, not a guaranteed duration. Some activities overlap; complicated transitions may need additional phases.
Scroll horizontally to compare all columns.
| Phase | Work | Gate to continue |
|---|---|---|
| Before notice/cutover dates are finalized | Review agreements, business events, access, billing, and service dependencies | Authorized transition plan and responsibilities |
| Discovery and preparation | Reconcile inventory, obtain records, identify gaps, schedule vendor participation | Critical systems and unresolved risks documented |
| Parallel validation | Test incoming access, coverage, ticket routing, and recovery | Evidence supports safe assumption of responsibility |
| Agreed cutover window | Change support routing and agreed management responsibilities | Business and technical owners accept the cutover checklist |
| First 30 days after cutover | Track issues, verify coverage, remove approved legacy access, prioritize improvements | Stable ownership and accepted remaining backlog |
“Parallel validation” does not mean installing conflicting endpoint products side by side. Check vendor-supported coexistence, migration order, and rollback steps for each tool.
Cutover acceptance checklist
- Named operators can access the systems they are authorized to manage.
- Support requests reach the new queue and the escalation path has been tested.
- Critical users can sign in and complete representative business tasks.
- Monitoring and protection cover the agreed inventory, with exceptions recorded.
- Required recovery data remains accessible and a representative restoration was checked.
- Open incidents, vendor cases, scheduled jobs, and renewals have owners.
- Business contacts know how to report disruption and authorize urgent action.
- The previous operating path can be restored where technically feasible; irreversible steps have explicit approval.
If a critical check fails, delay the affected change or use the agreed fallback. Do not treat a date on the calendar as authorization to remove access or delete recovery data.
Stabilize before starting every improvement project
During the first few business days after cutover, review failed requests, missing devices, access issues, and protection gaps frequently. Then move to a cadence appropriate to the remaining risk. This is an example operating rhythm, not a promised service level.
Within the first 30 days, reconcile recurring issues, confirm owners and backups, review remaining vendor dependencies, and create a prioritized improvement backlog. Separate pre-existing problems from transition-caused incidents so that remediation and commercial discussions are fair.
Agree access revocation at cutover rather than leaving outgoing privileges open indefinitely. Any temporary overlap needs a named owner, minimum necessary permissions, and an expiry. Rotate transferred secrets and revoke obsolete delegated access, accounts, and tokens through a dependency-aware plan. Suspected compromise follows the authorized incident process and may require immediate containment rather than waiting for the transition to finish.
Remove legacy tools after replacement coverage, retention obligations, and rollback needs are resolved. Record what was removed, who approved it, and what records the business retains. Keeping required historical records does not require keeping a former provider's administrative access active.
Common questions
Can we switch without downtime?
Some changes can be made without planned user interruption, but that is not a blanket guarantee. Identify which activities affect authentication, networks, applications, or endpoint software and agree a window and recovery approach for each.
What if documentation is incomplete?
Treat discovery as explicit work. Validate ownership and dependencies before assuming they are covered. Do not invent a short fixed timeline when basic access and recovery remain unknown.
Plan the handoff around your business
Contact Us About Your MSP Transition with your intended timing, approximate environment size, and known constraints. Share sensitive records only through a later agreed secure process. If responsibilities are still unclear, start with the co-managed versus fully managed comparison.