Microsoft 365 Tenant Handover Checklist for MSP Changes

Changing Microsoft 365 providers should not feel like moving a building. The tenant, domains, identities, and data usually stay where they are. The risk comes from everything around them: undocumented configuration, delegated admin access, hidden licences, stale recovery methods, and a departing provider that knows more about the environment than the client does.

Treat the handover as a controlled change, not an email exchange. The objective is simple: the organisation keeps administrative control, security visibility, service continuity, and enough documentation to operate without the outgoing MSP.

Before the Handover: Establish Control

Start with access that belongs to the organisation, not to an individual technician or provider.

Confirm These Accounts

• At least two organisation-controlled Global Administrator accounts
• Two emergency or break-glass accounts stored securely and excluded from normal Conditional Access lockouts
• Recovery email addresses and phone numbers controlled by the organisation
• A current list of administrators, service accounts, and automation identities
• A tested sign-in path that does not depend on the outgoing MSP’s phone or authenticator device

Do not remove the outgoing provider’s access before the new provider can sign in and the organisation can confirm that its own recovery path works. Record the change window and the person responsible for reversing it.

Identity and Entra ID Checks

Microsoft Entra ID is the control plane for the tenant. Review it before the handover, because a missing identity dependency can become an outage after the provider changes.

Check and document:

• Custom domains and domain registrar ownership
• DNS providers and the location of DNS credentials
• Entra Connect or cloud sync servers, if hybrid identity is in use
• Synchronisation scope and service account ownership
• Conditional Access policies and their exclusions
• MFA registration coverage and authentication methods
• Privileged Identity Management assignments and activation settings
• External users, guest access, and cross-tenant relationships
• Enterprise applications, app registrations, certificates, and client secrets
• Device registration, join state, and compliance dependencies
• Self-service password reset and authentication policy settings

Export configuration where the platform supports it, and keep a human-readable summary as well. A JSON export can preserve settings, but it does not explain why the settings exist.

Security Baseline Review

The handover is an opportunity to find controls that were added during an incident and never revisited. Ask the outgoing provider to explain every exception, exclusion, and high-privilege identity.

Review:

• Global Administrator and other privileged role assignments
• Inactive accounts and accounts with permanent privileged access
• Legacy authentication blocks
• Conditional Access exclusions and emergency access procedures
• Defender policies, alert routing, and incident response contacts
• Secure Score priorities and unresolved recommendations
• Audit log retention and who can search it
• Intune compliance policies, configuration profiles, and remediation scripts
• Endpoint detection and response onboarding status
• Mobile device management ownership and enrolment restrictions
• Security notifications and escalation paths

Do not accept “the policy is standard” as a handover explanation. The new provider needs to know what is standard, what is client-specific, and what is currently compensating for a known limitation.

Licensing and Billing Reconciliation

Licensing errors often hide inside an MSP relationship because the client sees a consolidated invoice rather than the Microsoft subscription detail.

Build a line-by-line inventory containing:

Item	Record
Product and licence name	Exact SKU and service plan
Quantity	Assigned, available, and unused seats
Billing owner	Organisation, reseller, or outgoing MSP
Renewal term	Monthly, annual, or other commitment
Renewal date	Date and notice requirement
Assignment	Users, shared mailboxes, devices, or workloads
Business dependency	What stops working if the licence is removed

Pay special attention to Teams Phone, Power BI, Visio, Project, Defender, Intune, and add-on security products. These can be easy to miss when they appear as separate lines or are bundled into a managed service.

Confirm who owns the Microsoft customer relationship, the partner relationship, and the billing account. A client should not discover during termination that a service is on a provider-owned subscription with a different renewal date.

Exchange Online and Collaboration Services

Email is the most visible failure point during a messy handover. Capture the current state before changes begin.

Exchange Online

• Accepted domains and domain types
• Connectors, transport rules, and mail flow dependencies
• Anti-spam, anti-phishing, and impersonation policies
• Shared mailboxes, resource mailboxes, and forwarding rules
• Distribution lists, dynamic groups, and Microsoft 365 groups
• Mail-enabled security groups and their owners
• Retention, litigation hold, and eDiscovery configuration
• Third-party filtering, journaling, archiving, and backup services
• SMTP relay devices, applications, scanners, and line-of-business systems

SharePoint and OneDrive

• SharePoint sites, owners, and external sharing settings
• OneDrive retention and departed-user procedures
• Power Platform environments and connection references
• Power Automate flows, service accounts, and data connections
• Teams teams, owners, channels, apps, and guest access
• SharePoint sites or Teams workspaces that rely on a former employee’s account

Ask for a list of business-critical workspaces, not only a list of sites. A site with an unhelpful name can still be the system of record for finance, HR, or operations.

Intune and Endpoint Management

A tenant handover can strand devices when the old provider owns the enrolment process or keeps the only copy of deployment profiles.

Record:

• Windows Autopilot device identities and hardware hashes
• Enrolment Status Page settings
• Configuration profiles and assignment filters
• Compliance policies and Conditional Access dependencies
• Application deployment packages, detection rules, and supersedence
• Windows Update rings and feature update policies
• macOS, iOS, and Android enrolment profiles
• Local administrator controls and endpoint security policies
• Remote support tooling and uninstall procedures
• Device categories, naming standards, and ownership records

Test a representative device through the full lifecycle: enrol, receive policy, install a required application, satisfy compliance, and access the required services. A successful admin sign-in does not prove that endpoint management is ready.

Backup, Recovery, and Business Continuity

Microsoft 365 retention is not the same as an independent backup. Identify what the current provider protects, how it restores, and who can perform a recovery without waiting for the outgoing provider.

Confirm:

• The backup product and protected workloads
• Backup account ownership and administrative access
• Retention periods and immutable or isolated storage
• Last successful backup and last successful restore test
• Recovery time and recovery point expectations
• SharePoint, OneDrive, Exchange, Teams, and endpoint coverage
• Alert recipients and escalation contacts
• Contract end date and data export or deletion process

Run a test restore before the outgoing provider’s access is removed. A screenshot of a green backup dashboard is not evidence that a restore works.

Documentation Package to Request

Ask for the handover in a structured format. At minimum, request:

• Current network and identity diagrams
• Tenant and domain inventory
• Administrator and service account register
• Licence and billing inventory
• Conditional Access and security policy summary
• Exchange mail flow diagram
• Intune policy and application register
• Backup and recovery runbook
• Open projects, incidents, risks, and known errors
• Vendor and support contacts
• Scheduled changes and renewal dates
• List of scripts, automations, certificates, and secrets with their owners

Never request passwords in ordinary email. Transfer secrets through a password manager or another approved secure channel, then rotate credentials after the new provider confirms access.

Cutover Day Runbook

Use a written sequence with named owners:

1. Confirm the new provider can access the tenant and monitoring tools.
2. Confirm the organisation’s break-glass accounts work.
3. Record a final export or snapshot of critical configuration.
4. Confirm open incidents and active changes.
5. Change delegated administration and provider access as agreed.
6. Rotate credentials, certificates, and secrets owned by the outgoing provider.
7. Test sign-in, mail flow, Teams, SharePoint, OneDrive, device compliance, and alerting.
8. Confirm licence billing and support contacts.
9. Send the client a status summary with unresolved risks and next actions.

Keep the outgoing provider’s access during a defined overlap when the contract and security plan allow it. Remove access only after the new provider and the organisation have completed the validation checklist.

Thirty-Day Stabilisation Review

The handover is not complete when the new provider says hello. After 30 days, review:

• Tickets caused by missing documentation
• Policies that were copied without understanding their purpose
• Orphaned service accounts and applications
• Unused licences and unexpected billing
• Security alerts that nobody receives
• Devices that fail compliance or application deployment
• Recovery tests and unresolved technical debt

A good handover leaves the organisation with fewer dependencies on individual people. That is the real measure of success.

Related Reading

• Microsoft 365 Governance for MSP Tenants
• Microsoft 365 Governance Best Practices
• MSP Access Control Policies
• MSP Exit Strategy: How to Leave Without Disruption
• MSP Vendor Lock-In Avoidance