Can your team work from that export?
Reconstruct one working case from exported records before treating a download button as an exit plan.
Your export contains an open case, a customer name and a document called quote-v2. Which customer? Was that quote approved? What is the next person supposed to do?
The download finished successfully. The answers did not come with it.
Before a renewal or migration, give the export a job. Choose one piece of work that must survive the move and try to reconstruct it without opening the old application. A ZIP file full of business records deserves a better acceptance test than “yes, it unzips.”
In Buy the boring part, we recommend testing the exit before committing to a service. Here is what that test can involve.
Give someone a case to continue
Consider a fictional service business with an open case, C-104. A coordinator needs to identify the customer’s site, find the approved scope of work and establish the next action. For this exercise, they only need to prepare a handoff. They will not book a visit or contact a customer.
Use a folder of CSV files and readable documents as the temporary destination. That is enough to test this narrow information task. It would not replace the booking system.
The first package contains a case row marked “Open,” the customer name Northline and quote-v2.txt. Its customer list contains two Northline entries, one for the West workshop and one for the East workshop. The quote describes an optional inspection, but its contents say it is a draft.
The coordinator cannot establish the site from the name. They cannot establish the approved scope from the newest document. “Open” does not explain whether the customer is still considering the quote or waiting for an appointment.
None of those gaps is fixed by importing the same rows into a nicer interface. Choosing the first Northline and assuming version two is approved would manufacture facts the package does not contain.
These are deliberately constructed records, not a client incident or an export from a named product. They expose three questions an exit rehearsal should answer: does identity survive, does the supporting evidence survive, and does the state still mean something outside the application?
Reconstruct the decision
A revised package gives C-104 a stable customer ID, U-7. The customer table maps U-7 to the West workshop. It includes both quote versions, a document register and two history entries: the customer approved version one; a later edit added an optional inspection to version two, which remains a draft.
The case points explicitly to the approved document. Its state is “Awaiting appointment,” defined in the package as scope approved but appointment not yet agreed. The next action is to request appointment preferences, owned by the service coordinator.
| What the coordinator needs | Evidence in the revised package |
|---|---|
| Correct customer site | C-104 links to U-7, which identifies the West workshop. |
| Approved scope | The case identifies version one; its file is included. |
| Explanation for the newer document | History records the optional inspection as a later draft change. |
| Next action and owner | Request appointment preferences; service coordinator. |
The optional inspection stays unapproved. A migration should not promote it just because its filename has a larger number.
The relationships matter as much as the files. An attachment without its case, a status without its meaning, or an approval without its document can leave the next operator guessing. Stable identity and explicit ownership help preserve those distinctions; a matching row count cannot establish them.
For this example, the synthetic files were checked locally: the first package has two matching customer names and only the draft document; the revised package resolves the site, approved document, recorded approval and next action. That checks the constructed example’s consistency. It is not an independent operator trial, a vendor export test or evidence that a real migration is complete.
Check what the export was allowed to include
Scope matters before you inspect a single row. Which account produced the export? What could it access? Which dates, views, records and attachments were included?
For a concrete product example, Notion’s export documentation says pages the exporter cannot access are excluded, and some content may also be excluded by teamspace settings. It also says reuploading exported content cannot instantly recreate a workspace. Those are documented limits to plan around, not evidence that exporting is useless.
Ask the same scope questions of the product you use. Do not assume the person who can press “Export” can extract everything the business needs. Equally, do not widen access indiscriminately to produce a more impressive archive.
The destination needs its own access decisions. Our local-file example does not enforce the old application’s roles. Before using real records, establish who may receive the package and how the receiving system will restrict it. Recovering information and deciding who may see it are both part of the move.
Make the rehearsal harder to bluff
Choose a case with a consequential exception: an amended document, a renamed customer, a reopened request. Take a snapshot at a recorded cutoff and compare the export with the source at that cutoff. Later changes need separate treatment.
Give an authorized colleague the package, a definition of the task and a place to record gaps. Choose someone who did not prepare the export. Ask them to show where each answer came from. If they must phone the old system’s resident expert to explain a status, record the missing definition. That person’s memory is currently part of your export format.
Use a simple result record:
Task and cutoff: What must someone establish, as of when?
Package: Export date, account role, scope, format and included files.
Evidence: Record and document references supporting each answer.
Gaps: What required a guess, a source-system lookup or an unavailable file?
Decision: Accepted for this task, accepted with named limitations, or blocked. Who owns each repair?
Stop where evidence runs out. Keep the gap visible rather than silently filling it from memory and declaring the export a success.
Be precise about what passed
Our revised package supports preparing one case handoff from a fixed snapshot. It does not establish that staff can safely edit records, preserve access rules, send messages or reconcile changes arriving after the cutoff.
A usable archive lets you retrieve and interpret the information you retained. A migration test must also demonstrate the required work in the destination. A restoration test must show that the intended application and data can be recovered from the backup. Name the claim before accepting the evidence.
For a real move, extend the rehearsal to the workflows and exceptions that would stop the business. Agree how to handle changes during cutover and when the source can be retired. One reconstructed case is a useful first test, not permission to cancel the subscription tomorrow.
Keep buying ordinary software when it fits. Just make the exit plan survive someone trying to use it.
Product documentation checked November 1, 2026. Recheck current export scope and destination behavior before a migration.