You have decided to change IT provider. The proposal is agreed and a start date is pencilled in. The next question is practical: what has to happen before the new team can safely take responsibility?
Changing IT provider involves more than moving helpdesk calls. Someone needs to account for business systems, administrator access, licences, backups and the services that sit outside the main support contract. A clear handover plan helps prevent gaps and makes the first month easier to judge.
1. Put one person in charge of the transition
Name an internal owner who can make decisions and bring the right colleagues into the process. Ask the incoming provider to name its transition lead and agree the outgoing provider’s handover contact.
Use one action list with an owner, a due date and evidence of completion for every item. Keep unresolved decisions visible. “The providers are sorting it out” is not a useful status if nobody knows who is waiting for whom.
Agree what the new provider will own and what remains with your team or another supplier. This is particularly important with co-managed IT support, where an internal IT team and an external partner share responsibilities.
2. Understand the dates before setting the switch
Check the notice period, renewal dates and exit arrangements in the existing agreement. Ask for a written list of handover work, any associated charges and which services would end if the support contract ended.
Internet connections, telephone services, software subscriptions and backup storage may have different terms. Record those separately. Do not assume that a support start date also transfers every subscription or cancels every old service.
The NCSC’s guide to working with managed service providers recommends clear responsibilities, defined service levels and understood exit clauses. Use those principles to agree the scope before the transition starts.
3. Build an inventory the incoming team can verify
Ask for a current record of the environment, then have the incoming provider check it against what is actually in use. The handover should cover:
- Users, devices, servers, cloud services and important business applications.
- Domain registrations, DNS, website hosting, internet connections and telephony.
- Software licences, subscription owners, billing contacts and renewal dates.
- Backups, retention settings, security products and monitoring responsibilities.
- Network documentation, known issues and important supplier contacts.
Keep passwords and recovery details in an approved secure system. The general action list should identify who controls access and whether it has been verified, rather than contain the credentials themselves.
4. Check business ownership and administrator access
Confirm that your organisation has an authorised way to control its domain registrations and critical business accounts. Check that recovery contacts belong to the right people and that access does not rely on a former employee or a single supplier contact.
For Microsoft 365, distinguish the commercial relationship from administrator permissions. A licensing arrangement and delegated access are separate matters to review. Microsoft provides a customer process for ending a granular delegated administrator relationship; removing access should be coordinated with the wider handover.
The new provider should explain the access it needs, how it will protect that access and how you can review it. Agree when the old provider’s access can safely be removed. Do not revoke access while it is still required for an agreed recovery or handover task.
5. Make security and backup coverage explicit
Draw up a change schedule for endpoint protection, monitoring, patch management and backups. For each service, record when the new arrangement will be checked and who will approve retiring the old one.
Some tools can conflict when installed together. Others need a carefully managed overlap. Ask the providers to agree the sequence, using the relevant product guidance, so staff are not left with a gap in coverage or a device that cannot work.
Confirm which backup history must remain available and who will maintain it. A new backup job does not automatically preserve access to older recovery points. Include a controlled restore check in the acceptance plan and address any dependencies before ending storage or licences.
6. Agree how you will accept the handover
Choose practical checks that reflect a normal working day. A small representative group should be able to sign in, access the right files and applications, use remote access where required and contact the new support team.
Set clear conditions for proceeding, stopping or rolling back a change. Include business owners in the checks. An engineer confirming that a system is available is different from a colleague confirming that they can complete their work.
Tell staff when the support route changes, where to log an issue and what to do if normal communications are unavailable. Make that message easy to find.
7. Review the first 30 days against evidence
Use the first review to confirm that access changes are complete, monitoring covers the agreed assets and urgent issues have owners. Ask for a prioritised improvement plan with responsibilities and target dates.
Compare the new service against the reasons you changed provider. If recurring incidents drove the decision, track their causes and recurrence. If visibility was the problem, agree a short report that shows risks, actions and progress. Separate an initial response to a ticket from the time taken to restore the affected service.
Planning a change of IT provider? Explore CIS managed IT support and talk to us about your handover requirements. Bring the key renewal dates, known issues and the outcomes you want from the new relationship.
