A customer export should survive the first question asked of it

An export finishes, the expected number of rows appears and the file opens successfully. Those checks establish useful facts. They do not establish that a customer can understand its work after leaving the application. A closed exception case may depend on an attachment, a review decision or the relationship between several versions. If those connections remain available only inside the supplier's product, the exported row can be a signpost to evidence the receiving team cannot reach. I want an exit rehearsal to discover that problem while there is still time to repair it responsibly.

Ask the receiving analyst to do the work

Our rehearsal covered 36,000 exception cases for a departing institutional customer. The first check confirmed the expected row count and a readable export. A receiving analyst then tried to investigate selected cases and found attachment references that did not lead to files in the supplied package. The review identified 2,400 such references. The export had preserved the case list but not every relationship needed for the agreed review task. A successful technical download and a useful operational handover had diverged, even though the initial checklist made them appear to be the same result.

The analyst's task was a better test because it exercised the purpose of the record. Could someone understand why the case had been closed and locate the relevant evidence? That question revealed a gap that a row count could not. It did not make the row count irrelevant. We still needed to know whether the population was complete. We needed additional evidence about usability. I prefer this combination of checks to replacing one simple measure with another. Completeness, readability and interpretability answer different questions, and each can fail while the others appear satisfactory.

The task must be defined against the authorised scope. A customer may need its case records and supporting attachments, but that does not justify copying every table or file the application can access. Another institution's records, internal supplier material and restricted information may require different treatment. Product engineering should work with the contract owner and the people responsible for access and obligations. A broad database dump can be technically easy while creating a new problem. The goal is an export the customer is entitled to receive and can use for the agreed purpose.

We repeated the analyst's review after revising the package. The receiving team examined the evidence relationships and the mapping rather than accept a larger archive as proof that the gap had been resolved. This helped keep the repair specific. An export project can expand indefinitely if nobody states what the receiving user needs to establish. It can also close too early if the only definition of success is a file transferred. A practical review task gives both teams a way to discuss the result without pretending that the supplier controls every future use of the records.

Export the relationship as well as the row

A record's meaning often depends on its connections. An attachment belongs to a case, a later decision may revise an earlier status, and a reviewer may have acted in a particular capacity. The receiving system needs enough context to preserve the relevant relationship. That does not necessarily mean reproducing every screen from the old application. It means identifying which parts of the record are needed to explain the work. The product should document those parts in a form that does not require the original engineer's memory or continued access to a proprietary interface.

In our case, the revised package included the relevant attachments and an access mapping within the agreed scope. We preserved the connection between cases and files so the receiving analyst could follow it. The customer retained responsibility for its receiving environment, retention decisions and ongoing access arrangements. Our rehearsal did not certify those matters. I wanted that boundary stated because a supplier can otherwise drift into one of two unhelpful positions: claiming that a useful export proves the customer's entire transition is complete, or claiming that everything after a download is somebody else's problem.

The export design should also account for change over time. A field or relationship introduced in a later product release may not exist in older records. A receiving analyst needs to distinguish genuinely absent evidence from an export defect. Clear descriptions of versions and optional fields can help. The specific solution depends on the product, but the principle is straightforward: the package should explain enough of its own structure for a competent receiving team to interpret it. A file full of unexplained codes may preserve data while leaving the institution dependent on the supplier for every consequential question.

Testing this work only when a customer gives notice is expensive. By then, the timetable may be fixed and the engineers who understand an older feature may have moved. I want export capability reviewed when the product changes the meaning or relationship of records. This does not require a complete termination rehearsal for every minor release. It requires an awareness that a new feature can create a new portability obligation. The team should know which changes affect the exported account of the customer's work and what evidence is needed to show that the account remains usable.

Treat departure as a product responsibility

The repair cost Orevathi ₹18 lakh of additional engineering work. Finance questioned why a departing customer should receive work beyond the initial estimate. That was a legitimate commercial question, and the contract owner confirmed the scope before we proceeded. I supported the expense because the gap concerned the usability of the agreed export. We were not funding an unlimited redesign of the customer's future systems. We were making our own delivery meaningful. The distinction allowed management to approve a specific obligation rather than either reject all exit work or accept every request without examination.

There is a wider product lesson in that cost. If portability depends on a bespoke rescue effort whenever a customer leaves, the company has not understood the continuing burden of its record model. The cost should inform future estimates and design choices. It should not become an argument for making departure so difficult that customers remain by necessity. A durable commercial relationship should rest on the service the product provides. When an agreed exit is exercised, the company should be able to explain what it will deliver, the customer's responsibilities and the evidence that the handover meets its scope.

Directors can examine this responsibility without reviewing export schemas themselves. They can ask whether termination commitments have been tested, whether management understands the cost and whether a customer's records remain interpretable outside the product. They should also ask how access and scope are controlled during export. A board paper that says data is portable because a download button exists has not answered those questions. The relevant assurance comes from a defined task performed by a receiving team with a package that preserves the necessary evidence, together with a clear account of what remains the customer's responsibility.

The first question asked of an export is often more revealing than the last progress report produced by the export project. Can I understand this case? Where is the supporting document? Which decision changed the status? A useful package can answer within its agreed scope. Our rehearsal exposed a gap and required an expense we had not planned. Repairing it made the handover more credible and the product team more attentive to the records it was creating. That is the standard I want: the customer's ability to understand its own work should survive the end of its use of our application.