Keep a workable way out

A platform can make you less dependent on specialist labor while making you more dependent on the platform. That can be an excellent exchange. Independence from every vendor would require doing a great deal more work yourself.

The useful question is which dependency you are accepting, what it buys and what would make it unacceptable. An exit plan makes that trade understandable before circumstances force a move.

An export needs to preserve meaning

A file containing all your records may still be difficult to use elsewhere. Attachments can be missing, relationships can be reduced to unexplained identifiers, and custom statuses can lose their definitions. Possessing the bytes is different from possessing a usable account of the business.

The export also omits some of the system: rules, permissions, templates and staff habits. A credible exit estimate considers what must be reconstructed as well as what can be downloaded.

Try a representative export before the dependency becomes large. It should let someone outside the original tool understand a complete case, including its history and related records. This small exercise can reveal more about portability than a broad promise that “you own your data.”

Understand the tradeoff

GOV.UK’s guidance on technical lock-in recognizes that accepting a dependency can reduce complexity and delivery effort. Portability has a cost too, so the right answer depends on the value received and the consequences of being unable to move.

For a short-lived experiment, using a proprietary feature may be a sensible shortcut. For a core operational record expected to outlast several vendors, readable exports and well-understood data structures deserve more attention.

Do not confuse a custom build with independence. Custom software can depend heavily on a hosting provider, a specialist library or the only developer who understands it. Practical ownership and documentation matter in either approach.

Estimate a credible exit

Describe one plausible replacement route. It does not need a fixed product name, but it should identify the work involved: exporting and cleaning data, reproducing essential rules, changing integrations, training users and switching over safely.

Check contract and access terms early enough to influence the decision. Notice limits on exports, notice periods, continued access after cancellation and charges for assistance. Have the appropriate adviser review terms that carry material business risk.

Keep the estimate proportionate. A rough migration sequence with the major unknowns is more useful than a confident price based on an export nobody has tested.

Review when dependence grows

Revisit the exit plan when the platform begins holding more important data, supporting more teams or controlling a critical customer interaction. The decision that was reasonable for a small experiment may need adjustment as its role expands.

Useful improvements can be modest: a recurring export, a clearer system inventory or a documented integration boundary. Spend on flexibility where it protects a meaningful option.

If you are weighing a new platform, read build versus buy alongside total cost of ownership. The exit cost belongs in that comparison, even if you never expect to leave.