IT Support Handover Checklist When Changing Service Provider

Quick answer: When changing an IT Support provider, a business should use a clear handover checklist for admin accounts, passwords/MFA, network diagrams, servers, email, backup, licenses, devices, open tickets and SLA. Without a controlled transition, the new IT team may not have enough access to resolve incidents and the business can lose track of IT assets.

Why provider transition is risky

Many companies think changing IT providers only means signing a new contract and giving employees a new phone number. The harder part is operational knowledge: who owns admin passwords, which account controls the domain, whether firewall configuration is backed up, whether backup can be restored, who owns licenses and which tickets remain unresolved.

If the handover is weak, the new IT team becomes reactive from day one. Email issues, internet outages, full servers or data restore requests will take longer because access and documentation are missing. The business also struggles to separate old issues from new service responsibilities.

When should this checklist be used?

Use it when changing an IT outsourcing company, moving from internal IT to outsourced support, replacing a computer maintenance provider, changing server/email administrators or discovering that current IT documentation is incomplete. Even without changing providers, the checklist is useful for periodic IT asset audits.

The best time is at least one to two weeks before the old contract ends. Waiting until the last day to request passwords, network diagrams or backup information creates unnecessary risk. For servers, firewall, VPN, Microsoft 365 or multi-branch environments, a three-party handover session is recommended.

Group 1: Admin accounts and ownership

This is the highest priority group. The company must know which account is the true owner, which accounts are secondary admins, where recovery email goes, whose phone holds MFA and who pays for the service. If domain, hosting, Microsoft 365 or firewall are under a personal account of the old provider, operational risk is high.

Group 2: Devices, network diagram and infrastructure configuration

The device inventory should include firewall, router, switches, access points, servers, NAS, printers, CCTV/NVR if relevant, important workstations and spare devices. Each item should have location, management IP, serial number, warranty status, login account and config backup. In business networks, IP/VLAN/VPN diagrams are as important as passwords.

If the previous provider does not have a network diagram, the new team should survey and rebuild a minimum map: ISP links, firewall, switches, Wi-Fi, IP ranges, VLANs, servers, printers, NAS and VPN connections. This reduces incident resolution time and supports long-term business network management.

Group 3: Backup, data and restore ability

Backup is not only the existence of backup software. The business needs to know what data is protected, where copies are stored, the backup schedule, retention period, alert owner and whether restore has been tested. During provider transition, the new team should request a sample restore test: a file, mailbox, folder or virtual machine depending on the system.

Without restore testing, a company may believe it is protected while backups have been broken for months. This is why backup should have its own handover note, especially for accounting servers, file servers, NAS, customer data, websites and email.

Group 4: Open tickets, recurring incidents and support history

Old tickets show where the system is weak. If one branch repeatedly reports Wi-Fi problems, a printer frequently drops connection or email often lands in spam, the new team should know this from the beginning. Otherwise the first few weeks are spent rediscovering old problems.

Ask the previous provider to export tickets from the last three to six months, including issue type, requester, status, cause, resolution and remaining action. The new team can then classify them as closed, monitoring, improvement project or urgent follow-up.

Reference handover timeline

Common risks when changing IT vendors

Acceptance criteria for handover

A handover should only be considered complete after the receiving team has verified access, documentation, backup, devices and core support commitments. Receiving a spreadsheet is not enough. For important systems, the team should actually log in, inspect configuration, test backup, try the support channel and confirm contacts.

What to do in the first 7 days

During the first seven days, the new IT team should rotate critical passwords, check MFA, remove unnecessary admins, verify backup, update the network diagram, confirm inventory, open the new ticket channel and announce the support process to users. This is also the time to monitor new tickets closely and identify inherited issues.

Avoid large changes immediately unless there is a clear security risk. A better approach is to stabilize operations first, then create an improvement list: email standardization, Wi-Fi upgrade, faulty device replacement, license cleanup, MFA rollout or recurring reporting.

Communication plan for users and managers

A provider change fails easily when users do not know where to ask for support. Before the cutover date, the business should announce the new support channel, hotline rules, expected response time, what information to include in a request and what old channels will stop being monitored. Managers should also know how urgent issues are escalated and where monthly reports will be reviewed.

The announcement should be practical rather than promotional. It should tell employees how to report a computer issue, email issue, printer issue, network outage or software problem. It should also explain that private messages to the old technician are no longer the official support path. This reduces confusion and helps the new Helpdesk build clean ticket history from the first week.

Contract and responsibility boundaries

The handover checklist should separate operational handover from contractual responsibility. Some problems may have existed before the new provider takes over. Some improvements may require a separate project, such as network redesign, server migration, license cleanup or backup rebuild. If these boundaries are not written down, every legacy issue can become a dispute.

A good transition note should mark each item as accepted, accepted with risk, pending from old provider, pending from business owner or recommended as a future project. This gives management a realistic view: what is safe to operate now, what needs monitoring and what requires budget approval. It also protects the new IT Support process from being judged by undocumented legacy conditions.

How IT Systems supports IT Support handover

IT Systems can join from the assessment stage: asset checklist, admin access review, backup check, open ticket collection, support channel standardization and SLA design after transition. The goal is to prevent operational knowledge from being lost when the IT team changes.

After handover, IT Systems can implement an IT Helpdesk ticket process, monthly reporting and improvement roadmap. The scope can start small with Helpdesk, computers, email and network devices, then expand into servers, backup, security and system administration.

FAQ

Should the old provider hand over passwords?

Yes, but the business should transfer ownership to company-controlled accounts or add new admins, then rotate passwords and MFA after handover.

What if the old provider has no documentation?

The new team should resurvey assets, rebuild a minimum network map, verify access and record unknown areas as handover risks.

Should the old service stop immediately after signing a new vendor?

No. A short transition period helps collect documents, transfer open tickets, verify access and avoid user support disruption.