Present an Exit Route From a Product Without Promising Effortless Portability

The question arrives near the end of the call, usually from the person who has been quiet: "And if we want to leave?" The deck has an answer ready. There's a slide near the back with a screenshot of an export control and a line about open formats. The control almost certainly exists. The screenshot is probably accurate. Neither of those facts answers the question, because the question was about a future in which the customer is still doing the work that brought them to you, and a file that can be downloaded is not the same as work that can continue.

An exit story is about preserving usable work across a transition. That means naming what has to survive, saying which parts a documented export actually covers, and comparing the routes for getting the rest across, with the work and interruption each route creates left visible instead of folded into a reassuring adjective. You can do this in a sales conversation without producing a migration plan and without offering a legal opinion. You cannot do it by showing the button.

Name the usable work that must survive

Start from the customer's continuing task, not from your data model. A service that has to know whether a household is already being helped, and by whom, needs different things to survive than a team that stores finished reports for audit. The list is short but it rarely collapses to "the data":

Records — the field values themselves, the facts of each case.

Relationships — the identifiers that tie a case to a person, a household, an adviser, another case, an organisation. Identifiers are the most underrated part of any export. A table of values without them is a pile of rows that cannot be reassembled into the thing it used to describe.

History — the sequence of states, notes and decisions that explains why a record looks the way it does today. Current state is a value. History is the reasoning behind it, and they are stored separately far more often than people expect.

Configuration — the statuses, assignment rules, custom fields and permission roles that made the records behave as they did. There is usually no export for this at all, because it isn't data. It's structure.

Human knowledge — which fields people trust and which they have quietly learned to ignore, what a particular tag means when nobody documented it, how a case is triaged on a bad morning.

A downloadable table can preserve every value and still lose the third, fourth and fifth of those. And a familiar file extension — CSV, JSON, XML — tells you about the shape of the file and nothing at all about whether the receiving product can do anything useful with it. That gap is where most exit conversations go wrong, and the rest of this piece is about keeping it in view.

Separate three kinds of evidence

"We have an export" is doing at least three different jobs in a typical sales conversation, and they rest on different warrants.

A published export description is documentation. It answers: what is claimed to be in the file, as of which version, on which plan, with what excluded? It is a statement of intent about contents.

A performed migration with inspected results answers a different question: does this work for work that looks like ours? It is the only one of the three that can answer it, and it requires someone to have actually run the extraction, loaded the result, and checked what arrived.

A contractual commitment about access and retention answers a third question entirely: what is owed? How long does the data remain available after termination, in what form, with what notice, and does the agreement include any assistance. That is a fact about the contract, not about the product's capability, and the two are frequently confused in both directions.

Say which one you are offering. "The documentation says the export includes these fields" and "we ran this last year for a customer with a similar shape, and here is what needed fixing" are different sentences. Letting them blur together is how a deck ends up promising a migration it has never performed. Attach limits where they belong: a version, a plan tier, a configuration. A capability that exists in the product but not in this customer's setup is not available to this customer.

There is useful published framing for the argument, though not for the product claim. The UK's Government Digital Service guidance on managing technical lock-in in the cloud, in the readings recorded for this piece in September 2026, treats portability and switching as choices carrying technical and organisational costs, and dependency as a trade-off between useful capability and the work of changing providers. It does not treat an available export, or an open standard, as an effortless operational move. That is a good shape for a slide: dependency as a costed choice rather than a moral failing or a solved problem.

Its limits matter, though. It is UK public-sector technology guidance. It is not evidence about any particular product's export, not a migration plan, not a retention guarantee, and not a legal requirement for a private company elsewhere. It supports a way of framing the conversation. It supports nothing about your customer's specific move.

One case, one afternoon

Here is an invented construction to make the trade-offs concrete. Nothing in it has been run, no vendor's capability is being described, and no transfer has occurred. It is teaching material.

An advice service runs an incumbent case-management product. Its documented export produces each case's current field values, a case identifier, and identifiers for the people and organisations linked to it. The activity history — status changes, notes, reassignments — sits outside the export. The workflow configuration has no export at all; statuses, assignment rules, custom fields and roles would have to be assessed and rebuilt.

Take case 4188, currently open, assigned to one adviser, with no recent notes.

On Monday at 09:00, an extract is produced.

At 14:00, an adviser updates the case. She writes a note recording a phone call and the reason the household is waiting on a third party. She changes the status from "open" to "awaiting third-party response" and reassigns the case to a colleague. The product records that change in the activity log.

Watch what survives that afternoon and what does not.

The status is a value, and values are the easy part. A 09:00 extract carries "open." An extract taken after 14:00 carries "awaiting third-party response." Either way the field crosses cleanly.

The note is content that exists only in the activity log. It is not in the export. Unless it is obtained through some other route or retyped, it does not cross at all — and what it holds is exactly what a colleague picking up the case on Tuesday would need.

The reassignment is an identifier, and identifiers are in the export if you take it after 14:00. What isn't in the export is whether the replacement product has an account and a role for that person. An identifier carries meaning only where something can resolve it.

The status definition is configuration. Even when "awaiting third-party response" arrives intact as a value, the replacement can't display or route it until someone recreates that status in its workflow. The value crosses. The behaviour doesn't.

Four pieces, four different answers. Now the routes have something real to move.

Compare where the transition burden lands

The three routes below are usually presented as a safety ranking. They are better presented as three different places to put the same work.

Parallel operation keeps both systems live for the same continuing work. The 14:00 update lands in whichever system the adviser had open. Which means that by five past two, one system has the note and the other has a case that still looks open, assigned to the first adviser, with nothing to explain the change. Someone then has to decide which copy is authoritative and carry the difference across. The status restates in seconds. The note has to be copied or written again somewhere it never was.

This matters because a fallback only exists while somebody is keeping it current, and keeping it current is precisely the reconciliation work. If nobody is doing that, you don't have parallel operation. You have one live system and one convincing-looking backup that is quietly wrong. What the route buys is a working system to fall back to on the day something breaks. What it costs is per-case reconciliation for as long as both remain live, access to both, and a rule about which system is authoritative that someone actually enforces.

Staged transfer moves cases in cohorts across a boundary that means something in the work — a service line, a region, a case category. Put case 4188 in the second cohort. During the first cohort's live weeks, the 14:00 update is simply ordinary work, and it will be sitting in the incumbent when cohort two is extracted at its own cutover. Divergence per case is much smaller, because each case lives in one system at a time, and the unmoved cohort keeps its fallback for free by not having moved yet.

The cost moves to the boundary. Split by region and a household with cases in two regions ends up split: one case in the replacement, its related case still in the incumbent, and anyone working that household needs both systems open. Split by date and the same thing happens across the line. The relationship travelled as an identifier, so it can be re-established by hand, but nothing keeps it true while the two halves live in different places. Dual access runs for the whole staging period, and the staging period is longer than a switch. Note also that the moved cohort loses its fallback unless someone keeps the incumbent copy current — which is the parallel-operation cost arriving quietly at each boundary. The routes overlap more than the clean three-way comparison suggests.

A single switch concentrates everything into one window. Freeze at 17:00, replacement live at 18:00. The 14:00 update falls before the freeze, so a final extract carries the current status and the current assignee. The state crosses cleanly, and no divergence exists afterwards because only one system holds the case.

Two things don't improve with a cleaner cutover. The note still doesn't cross, because history was never in the export — that is a coverage problem, not a routing problem. And the status still has to exist in the replacement before anyone can see the value. Interruption is one window, which some customers prefer because they can plan around it. The recovery problem sits in the same window: if the extract turns out to be missing something, or the replacement can't represent a status, there is no maintained incumbent to return to. The freeze has to be real, too. Any edit made after 17:00 and before the incumbent is retired is outside the last extract.

No route is safer in the abstract. Parallel buys a fallback and pays in reconciliation. Staging buys smaller per-case changes and pays in boundary work and duration. A single switch buys one interruption and pays in preparation and recovery. Which is right depends on how long this customer's work can tolerate ambiguity and how much reconciliation capacity they have on a Tuesday. That's a question for them.

Present the supported route and the unresolved test

Recommend the route the evidence supports, and phrase it as coverage rather than success. If the export documentation is current and specific, and the customer's required fields are a subset of what is documented, and nothing has been tested, then the supportable sentence is: "The export covers these fields and these identifiers. It does not cover activity history. Here is how we would get history across, and here is who would need to confirm it arrived."

Then name the three confirmations and who owns each.

Export completeness — comparing the documented export against the fields and links this customer's work actually uses. Usually a migration owner on their side, working with whoever can produce a test extract on yours. They know what their caseworkers need; you know what the file contains.

Replacement usability — whether statuses, roles, relationships and history can be represented at all in the replacement. That belongs to whoever configures it, and it is a configuration assessment, not a data one.

Reconciliation responsibility — who decides which system is authoritative when the two disagree, and who carries the delta. On parallel or staged routes this needs a name and a rule. Unnamed, it lands on whichever caseworker notices the discrepancy, and gets improvised case by case.

Keep estimates and commitments in different grammar. "The extract should take half a day to produce" is a forecast. "We will keep the export available for thirty days after termination" is a commitment if the agreement says so, and an empty sentence if it doesn't. The common failure is an estimate that acquires the rhythm of a promise — "this is straightforward" — said about a thing nobody has done.

That also means watching the vocabulary. Portable and no lock-in are claims about outcomes. A documented export is a claim about contents. Don't spend the second word's credibility on the first word's meaning.

Instead of "Your data is yours. One click, everything out."

Try "The export carries case records and the identifiers that link them. Activity history and workflow configuration sit outside it. We would suggest staging by service line. The history decision and the reconciliation rule need an owner on your side, and here is who we would put on ours."

What can leave, and who owns the rest

Field values and the identifiers that make them meaningful can leave, in a documented format, as of the moment of extraction. That is real, and it is worth saying plainly.

History leaves conditionally, if it is retrieved by some other route and somebody decides what is worth keeping. Configuration leaves conditionally, if it is rebuilt by someone who understands what the old behaviour actually did. The relationships between cases and people leave conditionally, if the replacement models them and someone re-establishes them from the identifiers that survived.

What does not leave in a file at all is the knowledge in people's heads — the conventions, the shortcuts, the sense of which cases need a second look. That transfers by people working alongside people: a shadow period, paired work, a colleague who can be asked. It costs time in a way no export field will ever show, and it is the dependency most likely to be missing from a transition plan precisely because it never appears in one.

So the presentation ends with three names and one honest sentence. Who confirms that the export is complete for this customer's work. Who confirms that the replacement can hold what arrives. Who decides which system is authoritative while both are live. And underneath all three, the sentence the deck should be able to say out loud: here is what leaves on its own, here is what leaves if someone does the work, and here is who that someone is.

The export button can stay on the slide. Put beside it what the export contains, what it doesn't, and who carries the rest. That is a weaker promise than effortless, and a far better answer to the question that was actually asked.

Frequently asked questions

Why isn't an export button or downloadable file enough to answer a customer's exit question?

Because an exit story is about preserving usable work across a transition. A downloadable table can preserve every field value and still lose relationships, history, configuration and human knowledge. A familiar file extension like CSV, JSON or XML says something about the shape of the file, not whether the receiving product can do anything useful with it.

What are the three kinds of evidence that an exit claim may rest on?

A published export description is documentation: what is claimed to be in the file, as of which version, on which plan, with what exclusions. A performed migration with inspected results answers whether this works for work like ours, and requires someone to run the extraction, load the result and check what arrived. A contractual commitment about access and retention says what is owed after termination, in what form and with what notice or assistance. Say which one you are offering.

In the leaver example, what survives a 14:00 update and what does not?

The status is a value, so it crosses cleanly—open before the update, awaiting third-party response after it. The note exists only in the activity log and is not in the export, so unless retrieved another way or retyped, it does not cross at all. The reassignment is an identifier and is in a post-14:00 export, but it carries meaning only if the replacement product has an account and role for that person. The status definition is configuration and must be recreated before the replacement can display or route it.

How do parallel operation, staged transfer and a single switch differ in where the transition burden lands?

Parallel operation keeps both systems live for the same continuing work, buying a fallback but requiring per-case reconciliation, dual access and an enforced rule about which system is authoritative. Staged transfer moves cases in cohorts across a boundary that means something in the work, reducing per-case divergence but adding boundary coordination, dual access and a longer transition—and it can split relationships across systems. A single switch concentrates everything into one window, with one interruption and no fallback after cutover; the note still doesn't cross and the status still must exist in the replacement. No route is safer in the abstract.

What should a presentation say instead of promising effortless portability?

Recommend the route the evidence supports and phrase it as coverage, not success: what the export covers, what it does not, how the rest would cross, and who would confirm it arrived. Name owners for three confirmations—export completeness, replacement usability, and reconciliation responsibility. Keep estimates and commitments in different grammar, and don't use portable or no lock-in, which are claims about outcomes, as if they were claims about a documented export's contents.

Further reading

• Explain a Product Retirement Before Asking Customers to Migrate — For the mirror case where you retire a product and ask customers to migrate: state what ends first, then consequences, options and the next supported step.
• Build a Build-versus-Buy Presentation Without Treating Development as a Purchase Price — Useful when the exit conversation sits inside a build-versus-buy comparison, because it follows each route past handover and puts cancellation, export and decommissioning on one footing.
• Show How an Integration Works Without Calling Every Connection Native — When a surviving identifier must resolve in a replacement system, this shows how to describe one exchange from trigger to result, and name its boundary and owner.