An open API is not a complete software exit plan

An enterprise software buyer can receive a well-documented API and still face an expensive move to another product. The interface may expose current records but omit attachments, historical states or the meaning of custom workflows. The commercial question is therefore whether the organisation can leave with enough usable information to continue its work, at a cost and within a period it understands.

For a defense technology business, this matters on both sides of a sale. A supplier needs to explain how its customer can adopt the product without making an indefinite commitment to one implementation. A company buying internal software needs to preserve the ability to change its tools when its organisation, partners or requirements change.

Establish what the interface promises

The OpenAPI Specification version 3.2.0 describes a language-independent way to express HTTP API capabilities. An OpenAPI description can support documentation, client generation and other tooling. Its role is to make an interface understandable; a document describing that interface is not, by itself, evidence that every business record or product feature is transferable.

Ask the vendor what its API actually covers. A product can provide excellent access to active tasks while offering no export of historical discussions. Another can return document identifiers but require a separate process to retrieve the files. Neither situation is resolved by the existence of a machine-readable description.

Use a small inventory of the information that keeps the business running. For a hypothetical supplier-quality platform, this might include supplier identities, assessment results, attached certificates, approval history and links to corrective actions. Define which elements need to remain usable in another product and which can be retained in a separate archive.

This makes the exit discussion concrete. “API available” becomes several answerable questions about scope, access and destination use. It also helps the supplier avoid promising a complete transfer when its current capability is limited to a particular set of records.

Separate a readable export from a usable replacement

A receiving system must understand the meaning of the exported data. A status labelled “approved” could mean that an assessment passed, that a manager accepted an exception or simply that a document was reviewed. If the original product combines these meanings in one field, a new product cannot reconstruct them reliably from the word alone.

Documentation should explain relevant field meanings, identifiers, relationships and value conventions. The exit package may need the vocabulary used at the time a record was created, especially if the company changed its internal process during the contract. Historical interpretation should not depend entirely on asking a former administrator what a code meant.

In the supplier-quality example, a certificate attachment belongs to a particular assessment and period. Exporting a folder of files without those relationships transfers the bytes but leaves a reconstruction project. Keeping the links in an intelligible form can substantially change the work required from the replacement supplier.

This is why portability should be demonstrated through a destination use. Select a representative assessment, recover its supporting material and explain its approval history outside the original interface. The exercise does not require building a complete replacement system before purchase. It requires showing that the promised exit material can support the business purpose.

Estimate the work beyond data extraction

The UK Government's guidance on technical cloud lock-in, updated on 3 September 2026, treats portability as a trade-off against the benefits of a service. It recommends understanding switching time and costs, and recognises that open formats can help software customers retain control of their data. Accepting some dependence can be rational when the service delivers sufficient value.

The implication for a product evaluation is to estimate an exit that could actually happen. Extraction is one part. Other work may include choosing a replacement, mapping fields, recreating permissions, training staff, validating records and operating both products during a transition. A quoted export fee does not describe that entire effort.

Consider two hypothetical offers. Product A includes a bulk export but requires the customer to reconstruct its approval rules. Product B supplies documented histories and relationships but charges for assisted extraction. The cheaper export can still produce the more expensive exit. Compare the expected tasks and who performs them before drawing a commercial conclusion.

Keep the estimate proportionate to the application. A simple internal directory may need little more than a clean file and a known mapping. A product governing years of supplier assessments has different continuity requirements. The same generic exit clause should not substitute for understanding those different uses.

Check whether the process works at the expected scale

A demonstration that retrieves ten records says little about extracting several years of information within an agreed transition window. The vendor should explain whether the intended route is a bulk export, repeated API requests or an assisted migration service. Each creates different dependencies and delivery commitments.

Relevant questions include the permitted request volume, attachment handling, the availability of historical versions and the treatment of records that change during the export. These are commercial capacity questions rather than an invitation to work around platform controls. The buyer needs the authorised process and its expected limitations.

The extraction timetable also depends on people. If only one named administrator can request an archive, the customer needs to maintain that access and understand the recovery route. If vendor assistance is required, the contract and operating arrangements should explain how it is requested and scheduled.

For the supplier-quality platform, the business may need active assessments to continue while closed assessments are moved. Agree how the final changes will be captured and which system supplies the authoritative status during the transition. A complete historical archive does not settle the handling of work still in progress.

Preserve access without broadening it

An exit should carry the permissions and ownership context needed by the receiving organisation. A bulk export that collapses carefully separated information into one unrestricted file can create an adoption problem for the replacement team. Decide who may receive the material and how the receiving product will reproduce the relevant boundaries.

The distinction between successful authentication and permission to see a particular record is examined in enterprise AI access controls. The same distinction matters when reconstructing a software environment. A valid account in the new product does not establish that its user should inherit every exported record.

Ownership of information also deserves an explicit conversation. The customer may hold records that include material supplied under a partner's terms. A vendor's technical export capability does not decide whether the customer has the right to reuse that material in every destination. Resolve such restrictions with the relevant parties before treating the entire archive as freely portable.

These details can be captured in an agreed exit scope. The purpose is to identify the usable information the customer can take, the authorised recipients and any dependencies that require separate action. That scope should be understandable to the business owner as well as the integration team.

Maintain the exit evidence as the product changes

A credible exit plan can decay as a product gains new features. A customer adds a custom assessment type, starts attaching larger files or introduces a new partner workflow. The original export demonstration may no longer represent the information that matters most.

Choose a sensible point to revisit the evidence, such as a substantial product change or contract review. Repeating a representative export and destination-read exercise can reveal gaps while there is still time to resolve them. The frequency should follow the rate and importance of change, not an arbitrary ritual.

Data migration acceptance provides the complementary handover perspective: population, relationships, transformations and business tasks need to be reconciled before the receiving system is accepted. An exit package becomes more valuable when it anticipates that eventual acceptance process.

The resulting commercial promise should be specific. The supplier can state which information it will provide, in what form, through which authorised process and with what assistance. The buyer can then decide whether the product's value justifies the remaining dependence. A documented API supports that decision, but useful exit evidence carries it through to the customer's next system.