Changing IT service provider: the reversibility checklist to avoid losing code, data, or access

A change of provider becomes difficult when the client discovers late that the domain, cloud account, repository, or email service was created in the name of a third party. Even when the relationship is good, incomplete handover can slow down maintenance for weeks.

Reversibility refers to the ability to transfer the operation and development of a system without losing its assets, data, or continuity. It is prepared from the beginning of the project and is regularly checked. This guide is technical and organizational; contractual clauses must be adapted and validated by legal counsel.

Real property matters more than the possession of a copy

Receiving a code archive does not guarantee autonomy. You need to know the history, private dependencies, build instructions, component rights, and the location of secrets. Similarly, a basic export is only useful if it is complete, documented, and restorable.

For each asset, ask four questions:

1. Who is the contractual holder?
2. who has administrator access?
3. how can the asset be exported or transferred?
4. Has the procedure been checked?

This distinction between 'received' and 'verified' avoids a false sense of security.

The eight asset families to inventory

1. Source code and build chain

Repositories, branches, tags, history, submodules, private packages, scripts, sample configuration files, integration pipeline, container images, and mobile artifacts. The client must have administrator access or a transferable full copy.

Keys and tokens must not be embedded in the code. They are inventoried by usage and recreated in the client's accounts.

2. Data and files

Databases, object storage, media, necessary documents, logs, search index, and analytical data. The export must include the schema, encodings, relationships, volumes, retention rules, and an integrity check.

A restoration in an isolated environment constitutes the best proof of transferability.

3. Infrastructure and environments

Cloud, servers, containers, network, firewall, CDN, managed databases, scheduled tasks, workers, backups, monitoring, and staging environments. The resources must be mapped with their region, cost, owner, and dependency.

When the infrastructure is codified, the repository and the associated state are part of the transfer.

4. Domain Names and Certificates

Registrar, DNS, zones, TLS certificates, renewals, subdomains, redirects, and email validation. The domain holder must be the client or an entity explicitly authorized with a documented transfer procedure.

5. Third-party services

Payment, email, SMS, mapping, search, authentication, analytics, storage, AI, and support tools. For each service: contract, owner account, plan, limits, keys, webhooks, hosted data, and exit procedure.

6. Documentation and business knowledge

Architecture, flow, data model, deployment, backup, incidents, glossary, business rules, exceptions, tickets and decisions. The documentation must be tested by a person who does not already know the system.

7. Intellectual Property and Licenses

Assignment or license contracts, open source components, fonts, images, commercial libraries, and rights on creations. The goal is to know what the client can modify, use, and transfer.

8. Operation and governance

Contacts, on-call duty, service levels, maintenance schedule, open incidents, vulnerabilities, roadmap, budgets, validation procedures, and user accounts. The handover must include daily operations, not just technical assets.

Prepare the transfer in four steps

Step 1 — Freeze the inventory

Establish a dated version of the asset list and identify the unknowns. Freezing does not mean stopping the project, but having a common basis to track changes until delivery.

Step 2 — Secure the client's accounts

Create or confirm the administrative accounts belonging to the client. Enable strong authentication and set recovery contacts. The provider's access remains personal and revocable.

Step 3 — Submit and verify

The new team clones, builds, deploys, and restores in a controlled environment. It compares the volumes and tests the critical paths. The discrepancies become actions with an owner and a deadline.

Step 4 — Revoke and monitor

After acceptance, secrets are renewed, unnecessary accounts are deleted, and logs are monitored. Access required for a transitional support period is time-limited.

The minimum content of a reversibility file

The file must allow a competent team to pick up without relying on private conversations. It contains:

• inventory of assets and owners;
• architecture and flow;
• startup and deployment procedure;
• backup and restore;
• environment matrix;
• third-party services and contracts;
• access transmitted, without including the secrets in plain text;
• known incidents and risks;
• backlog and roadmap;
• verification report.

When the former provider does not cooperate

Start with the assets held directly by the client: contracts, invoices, domains, accounts, data, and accessible deposits. Formalize the requests precisely: asset, format, date, means of transmission, and verification criterion.

The new team can rebuild an architecture from DNS, consoles, code, and logs, but this work must be identified and budgeted. Do not delete an unknown resource simply because it appears to be inactive.

Contractual disagreements must be separated from the continuity plan. The immediate goal is to protect the data, the service, and the evidence.

The technical clauses to anticipate

Without drafting the contract in place of a lawyer, the technical specifications can specify:

• export formats and their frequency;
• the ownership of accounts and deposits;
• the delivery time;
• the included support volume;
• the expected documentation;
• the conditions for deleting copies;
• continuity during the transfer;
• verification methods.

These elements are more effective when they correspond to procedures that have actually been tested.

Test reversibility before needing it

Once a year, choose a critical asset and check its transfer: restore a backup, clone a repository with a new account, export users, or rebuild an environment. This test reveals silent dependencies and keeps the documentation up to date.

Reversibility must also be considered when adding a new service. A tool that is difficult to leave may be acceptable if its value and risk are understood; it must not become a lock-in by accident.

A healthy relationship relies on the client's mastery

A good service provider does not need to retain assets to build loyalty. The value of the relationship comes from knowledge, execution quality, and the ability to evolve the platform. The client retains their accounts, their data, and the freedom to decide.

Partitech knows how to take over applications developed by third parties and organize their maintenance, hosting, and modernization. We can also help prepare the reversibility file before a change becomes urgent.

To prepare for the next part, consult the method of First 90 days to resume the maintenance of an application, frame a complete technical audit of the application and anticipate it application maintenance contract. Also discover the Partitech services.

Official references

References checked on August 17, 2026:

• Partitech — Services ;
• ANSSI — Outsourcing and information systems security: a guide to managing risks.