What Should an IT Onboarding Plan Include After Switching MSPs

Article by Josh Holcombe | Posted on September 22, 2026

Changing managed service providers is more than handing over a help desk phone number. The new provider needs a reliable picture of your systems, access, security controls, business priorities, and unresolved risks before making meaningful changes. That groundwork helps protect daily operations while the relationship moves from one provider to the next.

For Florida business owners and IT leaders, the most useful plan is practical and assessment-led. It turns scattered information into documented decisions, separates urgent risks from longer-term projects, and gives everyone a clear basis for accountability. Start by defining what the incoming MSP must learn and verify during discovery.

Explore managed IT support for a more controlled provider transition.

What Should an IT Onboarding Plan Include After Switching MSPs?

An effective plan should answer six practical questions: What does the business have? Who owns each system? How is access controlled? Where are the risks? How will support work? When will the new provider review progress? The goal is not to change everything immediately. It is to understand the environment, protect daily operations, and create a documented path from inherited systems to dependable management.

MSP onboarding integrates the client into the provider’s systems and workflows. Without a structured handoff, overlooked credentials, legacy equipment, or unclear responsibilities can contribute to security vulnerabilities, downtime, and communication problems. A written checklist gives the business and the incoming provider a shared record of what has been reviewed and what still needs attention.

1. Start with discovery and business priorities

Begin by documenting the business-critical systems and recurring problems that led to the change. Discovery should cover networks, business applications, cloud services, devices, vendors, and existing security measures. The incoming provider should understand how employees work and which technology supports revenue, customer service, compliance, and continuity before making major changes.

IGTech365’s assessment-led process evaluates the existing environment, documents systems and processes, identifies vulnerabilities and inefficiencies, performs a gap analysis, and connects recommendations to business goals. That approach helps separate an urgent operational risk from a worthwhile improvement that can be planned responsibly.

2. Confirm ownership, inventory, and documentation

The checklist should record administrative accounts, passwords, domains, cloud platforms, backup systems, hardware, software, vendors, warranties, and renewal responsibilities. The business should retain appropriate ownership and administrative access rather than depending entirely on the outgoing provider. Useful oversight artifacts can include an asset inventory, network diagram, system notes, and recurring health summaries.

Inventory is more than a list of devices. It establishes what the new provider is expected to monitor, maintain, patch, support, or recommend for replacement. It also exposes gaps in documentation before those gaps become an emergency.

3. Establish the security and support baseline

Review user permissions, multifactor authentication, endpoint protection, patch management, backups, and recovery procedures. Clarify how users request help, how issues are escalated, which systems require priority attention, and who approves changes. The plan should also identify compliance considerations such as HIPAA, PCI DSS, SOX, GDPR, or IRS data protection requirements when they apply to the industry.

Finally, document the first review point and the evidence that will be examined. Ongoing managed IT services can include monitoring, help desk support, workstation and server management, network administration, lifecycle management, patching, and updates, but the right scope should follow the assessment. A strong onboarding plan turns the provider switch into a controlled process with clear ownership, visible risks, and practical next steps.

How Do You Transfer Access, Accounts, and Ownership Safely?

Access transfer is more than handing over a password spreadsheet. The business should remain the owner of its technology, while the incoming MSP receives the access it needs to support that environment. A trustworthy provider should be able to give the business administrative access, documentation, and system credentials rather than keeping essential control inside a provider-only account. Administrative access and credentials are central to a responsible MSP handoff.

1. Build an ownership and access register

   Start with a list of every system that could affect daily operations. Include administrator accounts, password-management records, domains and DNS, cloud platforms, Microsoft 365, backup systems, network equipment, security tools, vendor portals, and software subscriptions. Record the business owner, the current administrator, the recovery email or phone, the billing owner, and where the credentials are stored. This register gives leadership a durable record of control instead of relying on an outgoing provider’s memory or portal.

2. Transfer administrative control to business-owned accounts

   Where possible, use an account controlled by the business, with named administrators and a documented recovery method. Do not make a personal mailbox, an individual technician, or an MSP-only identity the sole owner of a domain, tenant, backup console, or critical cloud service. Change passwords when control changes, and store the updated records in an approved password manager. The new MSP can receive delegated access or a named administrator role without becoming the permanent owner of the business’s core accounts.

3. Review Microsoft 365 and cloud subscriptions

   Confirm who owns the Microsoft 365 tenant, domain verification, global administrator roles, billing relationship, licenses, mail flow, and security settings. License or subscription management may require the business to authorize a transfer to the incoming MSP. Document which licenses are assigned, which are unused, and who approves future changes. For a structured review of tenant administration and account management, see Microsoft 365 administration.

4. Reconfigure MFA and recovery paths

   Review multifactor authentication on every administrator account, not just user mailboxes. Remove an outgoing technician’s authenticator, phone number, recovery email, hardware token, or emergency access method when it is no longer authorized. Then confirm that the business has its own tested recovery path and that more than one appropriate person can respond to an account lockout. Document emergency access without leaving permanent, unnecessary privilege in place.

5. Verify backup ownership and access

   Confirm that backup consoles, encryption keys, retention settings, recovery credentials, and billing records are accessible to the business and the incoming provider. Ask how a restore would be authorized if the MSP were unavailable. Access should support both routine administration and an urgent recovery, with permissions limited to what each role requires.

6. Restrict outgoing MSP access and retain the records

   After the handoff is verified, remove or disable outgoing provider accounts, API keys, remote-management agents, VPN access, shared mailboxes, and delegated roles that are no longer needed. Coordinate the change so legitimate transition work is not interrupted, but do not leave broad access active indefinitely. Keep the final ownership register, credential locations, authorization history, and offboarding date with the business. For a broader framework covering identity, permissions, and account governance, review business identity and access management.

Which IT Assets and Documentation Should the New MSP Inventory?

A useful inventory is more than a list of laptops. It gives the incoming provider a working map of the environment, shows who owns each system, and identifies what could interrupt daily operations. Discovery should cover devices, networks, business applications, cloud services, vendors, and existing security measures, not just the equipment that is easiest to see. Managed IT services are more effective when monitoring, support, maintenance, and planning are based on current documentation.

Ask the new MSP to record the business purpose, owner, location, management status, and known condition of each important asset. The inventory should also identify dependencies. For example, a line-of-business application may rely on a particular server, Microsoft 365 account, vendor connection, or network segment. That context helps the provider understand the business before making changes and prevents a seemingly minor adjustment from disrupting a critical workflow.

IT inventory and documentation areas to review during MSP onboarding

Area	What to verify	Why it matters
Devices	Workstations, laptops, mobile devices, ownership, location, operating system, warranty status, and management or patching status.	Supports lifecycle planning, reliable help desk service, and timely remediation of unsupported or unmanaged devices.
Servers	Physical or virtual servers, hosted workloads, roles, dependencies, storage, monitoring, and maintenance history.	Shows which systems support core operations and where performance, capacity, or failure risks may exist.
Network	Internet connections, firewalls, switches, wireless access points, VLANs, remote access, locations, and a current network diagram.	Provides a foundation for troubleshooting, secure administration, expansion, and continuity planning.
Applications	Business-critical software, versions, owners, integrations, data locations, renewal dates, and support contacts.	Connects technology to business processes and helps prevent unsupported software or overlooked dependencies.
Cloud	Microsoft 365, other cloud platforms, subscriptions, tenants, administrators, workloads, storage, and backup arrangements.	Confirms that cloud services are visible, governed, and not dependent on undocumented former-provider access.
Vendors and licenses	Vendor contacts, contracts, license owners, renewal dates, support terms, and authorized billing or administrative accounts.	Prevents missed renewals and clarifies who can resolve issues or approve changes.
Diagrams and health reports	Network and system diagrams, inventory reports, monitoring summaries, recurring issues, and open recommendations.	Creates an oversight record that can be reviewed as the environment changes. Periodic inventory reports, network diagrams, and health summaries are useful artifacts for this purpose.

Keep the documentation maintainable rather than treating it as a one-time handoff package. The incoming provider should update records as assets change, systems are retired, or new services are added. A clear inventory also gives business leaders a practical basis for separating urgent risks from planned improvements and for confirming that recommendations support operational goals.

IGTech365 begins service delivery with an assessment that evaluates the environment, documents systems and processes, identifies vulnerabilities and inefficiencies, and performs a gap analysis. That assessment-led approach can help a Florida business replace incomplete transition notes with documentation the team can actually use.

How Can You Validate Security, Backups, and Business Continuity?

Security validation should begin before the new MSP changes configurations. The goal is to establish a documented baseline, identify exposure created by legacy systems or unclear ownership, and confirm that the business can recover from a serious incident. A practical review covers permissions, multifactor authentication (MFA), endpoint protection, patching, monitoring, backups, and recovery procedures.

Start with the controls most likely to affect daily operations. Confirm that administrative accounts belong to the business, user permissions match current job responsibilities. MFA protects critical accounts, endpoint security tools are active, and operating systems and applications receive updates. An incoming provider should also document exceptions, unsupported devices, inactive accounts, and default or shared credentials rather than assuming the environment is secure because a tool is installed.

Review security across the environment

A useful baseline follows the major categories in the NIST cybersecurity framework. Inventory the assets that need protection, including endpoints, servers, cloud services, network equipment, and business applications. Then review identity management, authentication, and access control. These checks should answer who can access each system, why they need access, how privileged access is protected, and whether former employees or providers still have an account.

Next, verify data security and continuous monitoring. Monitoring should provide useful visibility into workstation health, server performance, software updates, storage capacity, and possible security events. NIST’s managed service provider guidance emphasizes asset management, identity and access controls, data security. And continuous monitoring because an MSP relationship can affect the security of every business it supports. A business cybersecurity risk assessment can help turn those findings into prioritized corrective actions.

Test recovery instead of trusting backup status

A backup dashboard showing successful jobs is not the same as proving that the business can restore its data. Confirm what is backed up, where copies are stored, how long they are retained. Who can access them, and whether the backup account is independent from the outgoing provider. Then validate recovery by restoring representative files or systems in a controlled manner and recording the results. The test should identify missing data, permission problems, application dependencies, and the practical steps required to resume operations.

Document the recovery plan, including responsible contacts, escalation paths, dependencies, and recovery priorities. IGTech365 describes business continuity support in terms of backup, disaster recovery planning, data protection, redundancy, recovery, and testing or validation. Learn more about backup and disaster recovery planning when the transition exposes gaps.

Account for industry obligations

Security controls should reflect the business and the data it handles. A healthcare organization may need to address HIPAA safeguards and documentation. Other environments may have obligations related to PCI DSS, SOX, GDPR, or IRS data protection requirements. Compliance does not replace technical validation, but it should shape the evidence, access rules, retention practices, and incident procedures the new MSP documents.

How Should Support Priorities and Responsibilities Be Set?

Support expectations should be clear before the first urgent issue arrives. A new provider needs to understand which systems keep the business operating, which problems have been recurring, and who has authority to approve changes. That discovery matters because the right first action for a manufacturing company may differ from the right first action for a healthcare practice. Law firm, or professional services business. A transition should be assessment-led, not treated as a universal handoff process.

Use the following sequence to turn those conversations into an operating plan:

1. Identify business-critical systems and operational dependencies. Document the applications, devices, networks, cloud services, and vendors that directly affect revenue, customer service, compliance, payroll, production, or employee productivity. Note what happens when each system is unavailable, who relies on it, and whether a workaround exists. The incoming provider should understand these dependencies before making material changes. Discovery should also surface recurring IT problems that have consumed staff time or remained unresolved. This gives the support team context instead of treating every ticket as an isolated technical event. Business-critical systems, security gaps, and recurring problems should be part of the initial discussion.
2. Define ticketing, urgency, and escalation expectations. Decide where employees submit requests, what information a ticket should include, and how the provider distinguishes an outage, a security concern, a user-impacting issue, and a routine request. Document who receives an escalation when a problem affects multiple departments or creates a potential compliance risk. Avoid inserting arbitrary response or resolution numbers unless they are actually part of the signed agreement. The useful outcome is a shared understanding of how issues enter the queue, how updates are communicated, and when leadership is notified.
3. Create an ownership matrix. Assign responsibility for monitoring, endpoint management, network administration, Microsoft 365, backups, security decisions, vendor coordination, user approvals, and business continuity. The matrix should name both the provider and the customer-side owner where appropriate. CISA recommends that MSP-customer arrangements clearly identify ownership of information and communications technology security roles and responsibilities: clear responsibility assignments reduce ambiguity during a security event. The matrix should also record who can authorize downtime, purchases, access changes, and larger remediation work.
4. Separate urgent risks from planned improvements. Not every finding should become an emergency project, and not every risk can wait. Prioritize issues that threaten active security, data protection, system availability, or critical operations. Then place larger improvements, such as hardware replacement, network redesign, lifecycle work, or application changes, on a roadmap with an owner and decision date. Some transition findings require hardware replacement or larger projects rather than routine support, so explain the risk and business impact before recommending a project.
5. Set communication and collaboration rules. Establish the regular meeting cadence, reporting format, decision-makers, and method for reviewing open risks. An internal IT team may retain day-to-day leadership while the provider supplies specialized expertise, monitoring, help desk capacity, project support, network administration, or coverage during absences. This co-managed IT model works best when both sides agree on boundaries instead of assuming the provider owns every technology decision. Revisit the matrix as systems, staffing, and business priorities change.

The result should be a practical support framework that connects technical work to business impact. It gives employees a predictable way to request help, gives the provider enough context to prioritize responsibly. And gives leadership visibility into what needs immediate attention versus what belongs in the longer-term IT plan.

What Should You Review 30, 60, and 90 Days After the Switch?

A 30-60-90 day review is a planning framework, not a universal promise that every MSP transition will follow the same schedule. The right cadence depends on the size of your environment, the condition of your documentation, the complexity of your systems, and the work authorized by your business. The purpose is to create deliberate checkpoints instead of assuming that the handoff is complete once the new provider can open tickets.

The first months after changing providers should focus on learning the environment, reducing risk, and strengthening the IT foundation without disrupting daily operations. Use each review to compare the original transition plan with documented evidence, record open decisions, and confirm which items need an owner. Managed IT services should support that visibility through practical reporting and ongoing conversations, not just a stream of technical alerts.

At 30 days: confirm access, inventory, and ownership

At the first checkpoint, verify that the new provider can support the environment without relying on informal knowledge held by the outgoing MSP. Review administrative accounts, passwords, domains, cloud platforms, backup systems, and any subscriptions that require an authorized transfer. Confirm that your business retains appropriate access and documentation, and that unused or unnecessary accounts have been disabled. CISA also recommends enforcing multifactor authentication on MSP accounts that access a customer environment and monitoring for unexplained failed authentication. Review CISA’s MSP access guidance when validating this handoff.

Ask for an inventory status, not merely an inventory claim. It should show what has been identified across networks, devices, applications, cloud services, vendors, and security tools, along with known gaps and assumptions. Note which systems still need ownership confirmation or deeper discovery.

At 60 days: review risk closure and support patterns

By the middle checkpoint, review what the transition uncovered and what has actually changed. Separate closed risks from accepted risks, deferred projects, and issues that require a larger hardware or infrastructure decision. Look for evidence that priorities are based on business impact rather than whichever request arrived most recently. Useful evidence may include recurring ticket themes, response and resolution trends, patching status, endpoint coverage, backup alerts, and unresolved access exceptions.

Also ask whether the support process is working for employees and managers. Are urgent issues reaching the right people? Are recurring problems being investigated at the root rather than repeatedly repaired? If an internal IT team remains involved, document who owns day-to-day support, security decisions, projects, and escalations. A co-managed IT arrangement can preserve internal leadership while adding specialized capacity, but the responsibilities still need to be explicit.

At 90 days: align the roadmap with the business

At the later checkpoint, turn findings into a forward-looking roadmap. Review the highest-priority risks, lifecycle needs, planned projects, budget assumptions, and dependencies with the leaders responsible for operations and growth. Confirm that recommendations connect to business outcomes such as continuity, productivity, compliance, or expansion, rather than becoming an unranked technology wish list.

Finally, revisit compliance obligations that apply to your industry. Healthcare organizations may need to examine HIPAA-related safeguards and documentation. Other businesses may have obligations connected to PCI DSS, SOX, GDPR, or IRS data protection requirements. These are not automatic deliverables or one-time deadlines. Treat them as requirements to validate with the appropriate business, legal, and compliance owners, then document the controls, evidence, and follow-up work that apply to your environment.

Call IGTech365 at (866) 365-7798 to discuss your transition plan.

Frequently Asked Questions

What should be included on an IT onboarding checklist?

Include ownership and access records, administrator accounts, passwords, domains, cloud platforms, Microsoft 365 subscriptions. Backup systems, device and application inventories, network documentation, security controls, support procedures, and known risks. The new provider should also identify business-critical systems and recurring problems before making changes, so urgent issues can be separated from planned improvements. Discovery guidance supports reviewing networks, applications, cloud services, devices, vendors, and existing security measures.

How do you transfer access safely when changing MSPs?

Confirm that your business owns and controls its technology, then move administrative access to accounts your organization manages. Review passwords, domains, cloud platforms, backup systems, and Microsoft 365 licensing. Restrict the outgoing provider’s access only after the handoff is documented and tested. Disable accounts that are no longer needed, and require multifactor authentication for MSP accounts that access your environment, as recommended by CISA.

Should backup testing be part of MSP onboarding?

Yes. Confirm which critical data is protected, where backup copies are stored, who can access them, and whether the recovery process works. A backup is not fully useful until you can restore the information your business needs. CISA recommends scheduled recovery tests to verify backup integrity and refine recovery point and recovery time objectives. Record the test results and assign an owner for correcting failures.

What should happen after the initial MSP handoff?

Use recurring reviews to confirm that documented risks are being addressed, monitoring and support processes are working, and the technology roadmap still matches business priorities. A 30-60-90 framework can organize those conversations, but the milestones should reflect your environment rather than a universal promise. Ask for evidence such as updated inventories, open-risk status, backup test results, and agreed priorities.

Ready to strengthen your MSP transition?

A practical IT health check can help you confirm ownership, identify gaps, and turn onboarding findings into a clear support plan. To request an assessment or start a conversation about managed IT support, call IGTech365 at (866) 365-7798.