What happens to your systems and documentation if you change outsourced IT providers?

In a properly managed change, the underlying systems usually remain in place while responsibility for operating, maintaining and securing them moves to the incoming provider. The main risks are not normally caused by the change itself, but by missing knowledge, unclear ownership, undocumented dependencies or access that is not transferred and reviewed correctly.

1. Establish the scope of the handover

Before any technical work begins, the business should confirm exactly what is changing. This may include service desk responsibility, network management, cloud administration, endpoint support, cyber security monitoring, backup management, procurement and strategic advice. It should also identify what remains with the business or another supplier.

The outgoing and incoming providers should work from the same list of services, locations, systems and responsibilities. This prevents assumptions such as believing that a third party manages a particular application, internet connection or backup platform when no one has formally accepted that responsibility.

2. Review the existing environment

The incoming provider will usually need to assess the current environment before taking operational responsibility. This review can cover:

• servers, workstations, mobile devices and network equipment;
• cloud services, hosted applications and virtual infrastructure;
• user accounts, privileged accounts and authentication methods;
• network diagrams, IP addressing, site connections and remote access;
• software subscriptions, support agreements and renewal dates;
• backup jobs, retention settings and recovery arrangements;
• security tools, policies, alerts and outstanding vulnerabilities;
• known incidents, recurring faults, technical debt and planned projects; and
• supplier contacts, warranties and escalation routes.

This assessment distinguishes between information that is complete and verified, information that is outdated, and information that is missing. It also gives the business a baseline against which later changes can be assessed.

3. Transfer operational knowledge

Documentation alone may not explain why a system is configured in a particular way or which services depend on it. A useful handover therefore includes structured knowledge transfer between the providers where appropriate. This may cover recurring maintenance, known workarounds, configuration decisions, unresolved issues and the practical sequence for dealing with common incidents.

The outgoing provider should identify any systems that require specialist knowledge, unusual support arrangements or manual intervention. The incoming provider should record questions and test its understanding rather than treating a folder of documents as proof that the handover is complete.

4. Confirm ownership and commercial rights

Changing IT providers does not necessarily transfer ownership of every account or asset. The business should establish who owns each domain, subscription, licence, cloud tenant, backup repository, certificate, hardware asset and configuration. Where an account is held in a provider’s name, the business may need to arrange a change of ownership or create a business-controlled account.

Contract terms can also affect the process. Notice periods, data return provisions, professional services charges, equipment leases, licence portability and restrictions on exporting data should be checked before the transition date. If information is held by a provider on the business’s behalf, the parties should agree how it will be returned, retained or securely deleted in line with contractual and data protection requirements.

5. Move access under controlled conditions

Administrative access should be transferred using named accounts, strong authentication and an agreed record of who is authorised to use each privilege. Shared credentials and personal email addresses create uncertainty over accountability and make it harder to remove access cleanly later.

Access should be reviewed by role rather than simply copied from the outgoing provider. The incoming provider may need new permissions, while former support accounts, temporary accounts and unused integrations may no longer be appropriate. Access to remote management tools, security consoles, backup systems and cloud administration deserves particular attention because these controls can affect the entire environment.

6. Test the important functions

A handover is not complete merely because the incoming provider can log in. The business should agree practical checks for essential services, such as user authentication, email, connectivity between locations, remote access, line-of-business applications, backup completion and restoration of selected data. Security monitoring and alert escalation should also be tested so that an event is not missed during the transition.

Testing should be recorded with the date, result, person responsible and any follow-up action. If a test cannot be completed, that limitation should be documented rather than assumed to be acceptable.

7. Record risks and outstanding work

The transition may reveal unsupported software, expired certificates, undocumented devices, weak permissions, failed backups or systems approaching the end of their useful life. These issues should be separated into immediate risks, planned remediation and longer-term improvement work.

A provider should not silently alter a production system simply to make the environment easier to manage. Changes should be authorised, documented and assessed for operational impact. Where urgent corrective action is required, the business should understand the reason, risk and proposed remedy.

8. Close the old arrangement securely

Once the incoming provider has accepted responsibility, the business should maintain a clear record of the transition date and the services transferred. The outgoing provider’s access can then be removed in a controlled sequence, taking account of integrations, monitoring agents, remote management tools and emergency contacts.

Before closure, the business should confirm that it has received the information and assets it is entitled to retain, including relevant records, configuration information and exportable data. The outgoing provider should confirm the treatment of any remaining copies in accordance with the contract and applicable data protection obligations.

Common causes of a poor transition

• starting the change without a complete list of systems and suppliers;
• assuming that the provider owns accounts that should be controlled by the business;
• relying on outdated diagrams or undocumented passwords;
• failing to identify dependencies between sites, applications and identity services;
• removing access before the new provider has completed validation;
• overlooking backup restoration, certificate renewal or domain administration; and
• treating discovered technical problems as part of routine support without agreeing priorities.

The business should retain a final transition record containing the agreed responsibilities, current system information, known risks, test results, outstanding actions and account ownership details. This becomes the starting point for ongoing IT management and reduces reliance on informal knowledge held by a particular supplier or individual.