Changing IT support provider safely means managing the exit and the incoming service as one controlled transition. Establish the contract and business deadlines first, create a complete inventory, move privileged access through named accounts and confirm the new support route before removing the former provider’s access.
Set the transition boundaries before giving notice
A provider change should begin with business rather than technical dates. Read the current agreement for notice, exit assistance, ownership and payment terms. Identify periods when disruption would be especially difficult, such as payroll, client deadlines, seasonal demand or planned changes. Name an internal decision-maker who can resolve questions about access, priorities and acceptable timing, then give the outgoing and incoming providers a common transition plan.
Avoid treating the notice date as the handover date. A practical plan includes discovery, information transfer, access changes, service-contact communications and a stabilisation period after the change. It should state who can authorise changes, how urgent incidents are handled during the overlap and when the former provider’s access will be removed. A clear boundary helps prevent gaps in responsibility or simultaneous uncoordinated changes.
- Check contractual notice, exit obligations and ownership terms.
- Choose dates that avoid known business-critical periods.
- Name one internal owner for decisions and approvals.
- Document incident handling during the transition window.
Build an inventory the incoming provider can use
An incoming provider needs more than a collection of passwords. Prepare an inventory of users, devices, servers, sites, networks, domains, internet connections, telephony, cloud services, licences, security products, backups and suppliers. Record the business purpose of important systems, current support contacts, recurring issues and work already in progress. This provides the starting point for accountable support and reduces the risk that a critical dependency is discovered only during an incident.
For each item, record a named owner, relevant supplier, renewal or contract information, administrative access route and any recovery details. Keep credentials out of ordinary documents; use a controlled password manager or another agreed secure transfer method. The inventory does not have to be perfect on day one, but it should make uncertainty visible so it can be prioritised. Missing information is a risk to manage, not a reason to assume the system is covered.
- Users, shared accounts, devices, servers and locations.
- Domains, DNS, Microsoft 365, email and cloud applications.
- Networks, broadband, mobile, VoIP and supplier contacts.
- Backups, security controls, licences, warranties and open work.
Move access through named, traceable accounts
Administrative access is one of the most sensitive parts of the handover. Identify tenant administrators, domain registrars, DNS, firewall, backup, security and supplier portals. Confirm who controls multi-factor authentication, recovery methods and emergency access. Where possible, create or validate named administrator accounts for the people who need them rather than continuing with shared credentials that obscure accountability.
Plan access changes in a sensible order. The incoming provider needs enough controlled access to understand and support the environment, while the outgoing provider may need retained access until specific handover work is complete. Record every material change, test that the intended administrators can sign in and retain a way to recover if an account becomes unavailable. Only remove former provider access after the new ownership and support route have been confirmed.
- List privileged accounts and their MFA or recovery arrangements.
- Use named administrator accounts wherever the service allows.
- Record access grants, tests, removals and outstanding exceptions.
- Remove former-provider access only after confirmation and validation.
Protect continuity while the service route changes
The transition plan should identify the systems whose interruption would have the greatest impact. These commonly include email, identity, line-of-business applications, shared files, telephony, connectivity and backups. Confirm current backup alerts, recovery contacts and supplier escalation routes before a major access change. NCSC response and recovery guidance is a useful reminder that preparation, roles and communications matter when a disruption occurs, not only the technical recovery steps.
Do not make wide configuration changes merely because a new provider has arrived. Start with visibility, account control and an agreed list of risks. Then sequence changes so they can be tested and communicated. If a critical incident occurs, use the documented escalation route and record what happened, who decided and what remains to be done. That creates a more stable foundation than attempting a complete redesign during an already sensitive transition.
- Identify the business systems that need a confirmed recovery route.
- Verify backup alerts, incident contacts and supplier escalation details.
- Sequence changes so their effect can be understood and tested.
- Keep an action log for risks, decisions and unresolved dependencies.
Communicate, stabilise and improve
Staff need a simple explanation of what is changing: the date, the new help route, the information to include in a request and the way urgent issues should be raised. Give the incoming provider the names of service contacts and a concise view of business priorities. Avoid asking users to diagnose technical issues; their role is to explain what they were doing, who is affected and whether a practical workaround exists.
After the handover, use the first weeks to stabilise the service rather than declare success immediately. Review early support patterns, incomplete inventory items, access exceptions, known risks and supplier relationships. Agree the next improvements with the business owner and record them in a manageable plan. A provider change is complete when responsibility is understood, staff know how to obtain help and the important unknowns have a named next action.
- Tell staff the new contact route, change date and escalation method.
- Give the incoming team context on priorities and recurring issues.
- Review early tickets, inventory gaps and access exceptions together.
- Turn the stabilisation findings into owned improvement actions.
Keep ownership clear if the plan changes
Transitions often change after discovery reveals an undocumented supplier, a critical integration or a date that cannot move. Treat this as normal transition governance: update the plan, explain the impact, obtain the appropriate approval and tell the people affected. A revised plan is safer than proceeding with a timeline that no longer reflects the environment or the business’s priorities.
Keep the inventory, access log and decisions available to the organisation, not only in a provider’s internal tools. At the end of the initial handover, agree which documents remain live, who maintains them and how the business can request them. This supports continuity if staff change and gives the new relationship a transparent basis for future service reviews or planned work.
- Update dates and dependencies when discovery changes the plan.
- Obtain approval before a material transition change.
- Keep business-owned copies of key handover information.
- Agree who maintains the inventory after stabilisation.
A provider change is not a substitute for due diligence
Every contract, technology environment and supplier arrangement is different. This guide cannot interpret your agreement or guarantee that an inventory is complete; obtain appropriate contractual or specialist advice where the transition raises legal, regulatory or technical concerns.
Decisions to make before the handover starts
Agree these points internally and place the resulting decisions in the transition plan.
- Who approves access and business-priority decisions?
- Which dates and systems must be protected from disruption?
- Where will secure access and recovery information be held?
- What evidence confirms that the new provider has taken responsibility?