Exit plans and avoiding lock-in in public sector software contracts

Every public sector software contract ends eventually. The question is whether it ends on the buyer's terms or the supplier's.

Lock-in happens when moving away from a system becomes so costly, risky or slow that the buyer has no real choice but to renew. It rarely comes from a single decision. It builds up through proprietary formats, undocumented integrations, knowledge held in one supplier's heads, and contracts that never defined what happens at exit.

We think avoiding lock-in is a supplier's responsibility as much as a buyer's. If a client stays with us, it should be because the service is good, not because leaving is too hard. Here is how we approach it.

Start with the Technology Code of Practice

Central government's Technology Code of Practice sets out principles for designing, building and buying technology. Several of them speak directly to lock-in, including:

Make things open and use open standards
Use open source where appropriate
Make better use of data
Avoid contracts that tie you to a single supplier
Use cloud first approaches

Many public bodies outside central government use the Code as a reference point too. It is a useful checklist when writing requirements and when reviewing a supplier's proposal.

Data ownership

The first question in any exit discussion is simple: who owns the data?

The answer should be the buyer, and the contract should say so clearly. That includes:

All data the buyer and its users put into the system
Data generated by the system in the course of the service, such as records, case notes, transactions and audit logs
Configuration that reflects the buyer's processes, such as workflows, templates and reference data

Suppliers will have their own intellectual property in the underlying software. That is reasonable. The line between the supplier's product and the buyer's data and configuration needs to be drawn before the contract is signed, not argued about at the end.

Open formats

Owning the data is only useful if you can read it. We make sure buyers can export their data in open, documented formats such as CSV, JSON or standard database dumps, along with a description of what each field means.

Good practice includes:

Self-service export that does not depend on a support ticket
A data dictionary that explains tables, fields, codes and relationships
Attachments and documents exported with their metadata, not as an undifferentiated archive
Regular test exports during the contract, so the exit route is proven before it is needed

Documented APIs

Integrations are where lock-in often hides. If other systems connect to yours through undocumented or proprietary interfaces, replacing your system means rebuilding every connection.

We publish API documentation as part of the service, using a standard description format where possible. Documentation should cover authentication, endpoints, data models, error handling and versioning. Where we build integrations for a client, we document them as client assets, so a future supplier can understand and maintain them.

Infrastructure as code

For systems we build and host, we define infrastructure as code. Networks, servers, databases, storage, permissions and monitoring are all described in version-controlled configuration rather than set up by hand.

This matters at exit because the environment can be recreated by someone else. A new supplier, or the buyer's own team, can read exactly how the service is set up and redeploy it in their own accounts. Combined with source code access where the contract provides for it, this removes much of the mystery that usually surrounds a handover. Our software engineering and managed services teams work this way by default.

Escrow versus documentation

Source code escrow is often proposed as a safeguard. A copy of the code is held by a third party and released to the buyer in defined circumstances, such as the supplier going out of business.

Escrow has a place, but it has limits. Code on its own, without build instructions, infrastructure definitions, dependencies, credentials handover and knowledge of how the system is run, can be very hard to use. Release conditions can also be narrow.

We would rather buyers have ongoing access to the things that make a system operable:

Source code in a repository the buyer can access, where the contract provides for it
Build and deployment pipelines that are documented and reproducible
Runbooks for routine operations, incidents and recovery
Architecture diagrams and decision records kept current

Where escrow is required, we treat it as a supplement to good documentation, not a substitute.

What an exit plan should contain

An exit plan should be written at the start of the contract and kept up to date, not drafted in a hurry when notice is served. Ours typically cover:

Scope: which services, data, integrations and assets are covered
Roles: named contacts on both sides, and any incoming supplier's role
Data: what will be exported, in what formats, how it will be validated, and when the supplier's copies will be securely deleted
Knowledge transfer: documentation, handover sessions and shadowing for the incoming team
Parallel running: how the old and new services will run side by side, if needed, and for how long
Integrations: how connected systems will be switched over
Security: revoking access, rotating credentials and transferring domains or certificates
Timeline: a realistic sequence of steps with dependencies
Costs: what exit assistance is included in the contract and what is chargeable
Testing: how and when the exit process will be rehearsed

Review the plan at least annually, and whenever the service changes significantly.

Contract terms that help

Buyers can reduce lock-in risk through the contract itself:

Clear data ownership and export rights
An obligation to maintain and update the exit plan
Defined exit assistance, with costs agreed up front
Rights to documentation and, where appropriate, source code
Reasonable contract lengths and break points

Contract terms depend on the buyer's own policies and legal advice, and on the current procurement rules, so check the relevant guidance for your organisation.

Talk to us

If you are planning a software procurement or worried about an existing system you cannot easily leave, talk to us. You can also read more about how we work with clients.