What should an MSP hand over when a company moves IT in-house? The handoff should cover company-owned administrative access, credentials, system and network documentation, asset inventories, software and vendor records, backup and recovery information, security configurations, open work, known risks, and the operational knowledge the internal team needs to support the business.
A good MSP exit should feel controlled and uneventful to employees. That outcome depends on preparation. If the business waits until the last week to ask for passwords and documentation, hidden dependencies can turn a planned transition into an emergency.
This checklist is designed for companies moving from a managed service provider to an internal IT department. For the broader operating model, read our guide to building or improving an internal IT department.
MSP handoff checklist at a glance
- Confirm what the company owns and what the provider licenses.
- Create a register of every system, service, vendor, account, and responsibility.
- Establish company-controlled administrator access before cutover.
- Collect current documentation in a usable, searchable format.
- Decide which MSP tools will transfer, remain, be replaced, or be retired.
- Schedule knowledge-transfer sessions with the people who know the environment.
- Test critical workflows before accepting the handoff.
- Remove obsolete access and rotate shared credentials after cutover.
- Keep a written record of incomplete items and who owns each one.
Start with the service agreement
Before asking for exports, review the current agreement, order forms, statements of work, license terms, and termination provisions. The contract may distinguish between company-owned systems and provider-owned platforms.
Look for answers to these questions:
- How much notice is required?
- Is transition assistance included or billed separately?
- Who owns the documentation created during the relationship?
- Who owns software subscriptions, tenant accounts, phone numbers, domains, and hardware?
- Can licenses transfer directly to the business?
- How and when will the provider remove its access?
- What data will the provider retain after termination?
- Are there early termination, export, or project fees?
This is an operational checklist, not legal advice. If ownership or termination language is unclear, involve qualified counsel before making assumptions.
Create an MSP handoff register
An MSP handoff register is a master list of everything being transferred, changed, retained, or retired during the transition. It gives the business and both IT teams one shared record of progress.
For every item, record:
- System or responsibility name
- Business owner
- Current technical owner
- Future technical owner
- Administrative account location
- Contract and renewal date
- Documentation status
- Transition decision
- Test or acceptance requirement
- Due date and current status
Use four clear transition decisions: transfer, replace, retain externally, or retire. This prevents the team from assuming that every provider tool should be copied into the new environment.
1. Identity, domains, and administrative access
Access is the first dependency because the internal team cannot operate or verify systems it does not control.
Collect and verify:
- Microsoft 365 or Google Workspace global administration
- Identity provider, single sign-on, and multifactor authentication administration
- Domain registrar, DNS, and certificate management
- Cloud hosting and subscription administration
- Local directory and server administrator accounts
- Firewall, switch, wireless, and remote-access administration
- Endpoint management and security console administration
- Backup and recovery platform administration
- Phone system, carrier, and number ownership
- Website, hosting, analytics, and related business accounts
- Service accounts, API keys, recovery codes, and encryption keys
Use named administrative accounts where possible. Store privileged credentials in a company-controlled vault, require multifactor authentication, and limit access according to role. Microsoft defines least privilege as giving users and applications only the access required to perform their work. See its least-privilege guidance.
2. Network and infrastructure documentation
Ask for current documentation, not a collection of old diagrams with no indication of what is still accurate.
The handoff should include:
- Physical and logical network diagrams
- Internet circuit details and provider contacts
- IP address ranges, VLANs, routing, and wireless networks
- Firewall rules, VPNs, and remote-access methods
- Server roles, virtual machines, storage, and cloud resources
- Equipment locations, models, serial numbers, and warranty status
- Configuration backups for network devices
- Monitoring methods and alert destinations
- Known single points of failure and accepted exceptions
Have a qualified internal team member walk through the diagrams against the actual environment. Documentation should explain how the system works today, not how it was designed several years ago.
3. Devices, software, and asset records
The new team needs to know what it supports and who uses it.
Request:
- Workstation, laptop, mobile device, server, printer, and network asset inventories
- Assigned user, office, department, and physical location
- Operating system, age, warranty, and replacement status
- Installed business software and license assignment
- Device enrollment and management status
- Endpoint security, encryption, and patch status
- Standard build, deployment, and replacement procedures
- Loaner, spare, and retired equipment records
Exporting an asset list is only the first step. Reconcile it against the identity system, endpoint platform, purchasing records, and physical inventory to find devices that are duplicated, missing, or no longer active.
4. Backup, recovery, and business continuity
Do not accept a green dashboard as proof that recovery works.
Collect:
- Systems and data included in backup coverage
- Systems and data specifically excluded
- Backup frequency, retention, storage location, and encryption details
- Recovery time and recovery point expectations
- Recent failure history and unresolved alerts
- Restore procedures and emergency contacts
- Results and dates of recent recovery tests
- Business continuity and disaster recovery plans
Run at least one representative restore before the provider leaves. The internal team should know how to request or perform recovery, where alerts go, and who makes the business decision to restore a system.
5. Security operations and compliance information
The internal team needs both the current controls and the known gaps.
Transfer:
- Endpoint protection, email security, vulnerability, and monitoring configurations
- Security alert routing and escalation procedures
- Incident response plans and recent incident records
- Access review history and privileged account records
- Security policies, exceptions, and accepted risks
- Cyber insurance control information and renewal dates
- Compliance evidence and outstanding remediation work
- Employee security training and phishing-test records
- Third-party access and vendor risk information
NIST Cybersecurity Framework 2.0 organizes cybersecurity risk around Govern, Identify, Protect, Detect, Respond, and Recover. Those functions provide a useful way to check that the handoff covers governance and recovery as well as protective tools. See the NIST CSF 2.0 resources.
6. Service desk history and operational knowledge
Ticket history contains information that may not appear in formal documentation. It shows which employees need specialized support, which systems fail repeatedly, and which fixes are temporary.
Request:
- Open tickets and current owners
- Recurring incidents and known workarounds
- Major incident history
- Employee onboarding and offboarding workflows
- Request and approval templates
- Support priorities and service commitments
- Knowledge-base articles and internal notes
- Open projects, risks, dependencies, and target dates
- Vendor escalation history and unresolved disputes
Do not import years of ticket noise without a plan. Preserve records required for business, legal, or compliance reasons, then extract the information the internal team will use.
7. Vendors, contracts, licenses, and renewals
MSPs often coordinate vendors on the client's behalf. When that coordination moves in-house, contracts and relationships need a named owner.
Document:
- Vendor name, service, account number, and support contact
- Business and technical owner
- Contract term, renewal date, notice deadline, and cancellation terms
- License count, assignment, and billing method
- Provider-owned versus company-owned subscriptions
- Current issues, credits, disputes, and planned changes
- Data export and termination requirements
Update vendor authorization records before cutover so the new internal contact can open cases and make account changes without waiting for the former provider.
Test the handoff before calling it complete
A document is not proof of operational control. Ask the internal team to demonstrate that it can:
- Create and secure a new employee account
- Offboard an employee and revoke active access
- Enroll, patch, and remotely support a workstation
- Respond to a security alert
- Restore a file or representative system
- Change a network or cloud configuration safely
- Open an urgent case with a critical vendor
- Find the owner and recovery plan for a business-critical application
- Communicate a major outage to employees and leadership
Record failed tests as open transition items with an owner and due date. Do not hide them inside meeting notes.
After cutover
Once the internal team has accepted responsibility:
- Remove provider access that is no longer required.
- Rotate shared and provider-known credentials.
- Review integrations, API keys, forwarding rules, and service accounts.
- Confirm that alerts and invoices reach current owners.
- Update employee support instructions.
- Confirm backup, monitoring, and security coverage.
- Review incomplete transition items weekly until closed.
- Schedule a 30-day post-cutover review.
Red flags during an MSP exit
- The provider cannot produce a current asset or system inventory.
- Critical accounts use provider-owned email addresses with no company administrator.
- Documentation exports contain passwords in unprotected files.
- The team cannot explain backup exclusions or show a recent restore test.
- Licensing ownership is unclear until the final week.
- Open projects and recurring incidents have no written status.
- Knowledge transfer is limited to sending files with no walkthrough.
- The internal team is expected to accept the handoff without testing access.
A red flag does not automatically mean the MSP acted improperly. It means the transition plan needs more attention before the business relies on the new operating model.
Get help managing the MSP handoff
Compass™ Internal IT Consulting helps businesses plan and implement the move from an MSP to internal IT. Spot On Tech can build the handoff register, map ownership, review tools and contracts, verify access, organize documentation, test critical procedures, and train the internal team.
After the handoff, use our internal IT tools guide to evaluate the new stack and our internal IT maturity assessment to prioritize the next improvements.
If your business is in New York or New Jersey, talk with Spot On Tech about your transition or begin with an IT assessment.
Frequently asked questions
Is an MSP required to hand over passwords and documentation?
The answer depends on the agreement, account ownership, license terms, and applicable obligations. Company-owned credentials, data, and systems should be identified early. Review the contract and involve qualified counsel if ownership or transition duties are disputed.
When should the MSP handoff process begin?
Begin before the final service date and, when possible, before formal notice limits cooperation or tool access. The internal leader should have enough time to inventory responsibilities, verify access, plan replacements, schedule knowledge transfer, and test critical workflows.
Should we keep the MSP during the transition?
An overlap period is often useful because it lets the internal team learn the environment and verify control while support coverage continues. The appropriate overlap depends on cost, contract terms, relationship quality, and operational risk.
What if the MSP owns the RMM or service desk?
Decide whether the license and data can transfer. If not, select the replacement early, plan device migration, export required records, recreate critical automations, and test the new platform before the provider removes access.
When should MSP administrator access be removed?
Remove access after the business has accepted the relevant handoff and the provider no longer needs it. Coordinate timing carefully so access is not removed before critical transfer work is complete. Then rotate shared credentials and review service accounts, API keys, and integrations.
Can Compass help if we are keeping part of the MSP relationship?
Yes. Compass can design a co-managed model that defines what the internal team owns, what remains with the provider, how tickets and alerts move between them, and who is accountable for each outcome.
