Key takeaway
A migration can preserve row counts while changing what those rows mean. Compare periods and definitions before presenting one continuous history.
Audit the boundary, not just the export
Write down the old system, new system, cutover date and migration method. Ask whether records were copied as event history, converted into current-state rows, or reconstructed from reports. These alternatives can produce similar-looking files with different evidence. An imported final status cannot establish the earlier sequence that produced it.
Zendesk’s audit reference shows a field-change event with previous and new values. That is one example of the distinction between a transition and a final value. An owner must inspect its own system’s actual export behavior; the vendor example does not prove that any particular migration retained or dropped events.
DCAT 3 includes version notes that can communicate a dataset change. The crosswalk below extends that idea into an operational comparison. It is a proposed audit method, not a standard’s mandatory migration checklist or a claim that a given archive has continuous coverage.
An illustrative period and meaning crosswalk
Suppose a company migrated its service system in July 2023. In this hypothetical archive, old closed meant the invoice was finalized, while new completed meant the technician marked the task finished. This is an invented source-system definition, not Zendesk’s definition. Renaming both fields outcome would create an unsupported equivalence.
The useful deliverable is a table that separates known changes from unverified assumptions. A reviewer can then choose a comparable subset, describe separate periods, or stop a proposed analysis. Do not replace missing historical evidence with today’s definitions.
| Period / field | Observed in the hypothetical audit | Evaluation decision |
|---|---|---|
| Before July / closed | Invoice finalization; no test requirement | Do not interpret as verified repair success |
| After July / completed | Task finish; outcome held separately | Use as completion evidence only |
| Imported records / event dates | Original open date retained; transitions absent | Exclude from duration tests needing transitions |
| Attachments across cutover | Old attachments were not in the inspected export | Describe export gap; investigate original storage |
| Job identifiers | Old job numbers can collide with new numbering | Use system and identifier together internally |
| Outcome labels | New vocabulary began after cutover | Compare only a documented compatible subset |
Test coverage with a bounded reconciliation
Select records from before, during and after the migration, including a case that stayed open across the cutover. For each, compare the source view, export and proposed package. Record which fields were present, which relationships survived and which discrepancies remain unresolved. Use permitted internal inspection; do not distribute raw examples merely to ask whether they are useful.
An illustrative audit checks 12 cases: four from each period. Two cutover cases lost action transitions in the proposed export, while all four recent cases retain them. Those counts describe the inspected sample only. They are not a basis for saying that half of all migrated cases are incomplete or that the recent archive is universally reliable.
Distinguish an export gap from a source gap. An attachment missing from the inspected file may exist in an authorized original store. If recovering it would require a broader disclosure or unreasonable effort, narrow the package instead of claiming the attachment never existed.
Decide what can be compared
Create an explicit comparability rule per analysis. A count of tasks opened may remain comparable when event-duration analysis does not. A recurrence analysis may need a stable asset relationship that the migration broke. There is no single yes-or-no answer to whether the whole archive is usable; the answer depends on the proposed question.
In the example, the owner offers post-cutover cases for a first duration evaluation and describes older cases as a separate descriptive archive. The evaluator receives the period limitation before seeing a performance result. If the older period is later reconstructed, it becomes a new documented package with a reviewable method, not an invisible patch to the original evaluation.
Keep confidence proportional to evidence. A systems administrator’s recollection can identify where to investigate, but should not replace the records needed to establish a field’s historical meaning. Mark disputed definitions and unknown coverage in the crosswalk until the responsible owner resolves them.
Set a recovery limit and a handoff record
Before reconstructing years of history, choose a small verification step, its owner and a stopping condition. Proceed if the missing relationship can be recovered within the permitted source systems and the method produces an inspectable result. Stop if reconstruction depends on guessing event order, inventing timestamps or assuming a discarded field’s meaning.
The inventory handoff should state usable periods, excluded periods, field-definition changes, remaining original stores and the limits of the reconciliation sample. These qualifications are part of the product description, not footnotes to hide after a buyer has formed expectations. They do not imply a price discount, buyer demand or rights to disclose. VOID can use the description for a scoped fit discussion before any sample decision.