You are moving to a new case-management product and the old one holds years of recorded execution history. How do you decide whether to carry that history across, and what do you do if you do not?

## Start with the demand, not the data The instinctive framing is *how do we move the history?* The useful framing is *who reads it, how often, and to answer what?* Almost every migration plan is improved by asking a few people that question before anyone estimates the work. The honest answers usually cluster into three: - **Has this ever passed?** Someone arguing about a shaky area wants to know whether a case has a track record. They want recent history, not years of it. - **What happened around this defect?** Archaeology on a specific incident, needing a bounded window and usually the evidence attached to it. - **Show me the record.** Someone outside the team who needs to see that something was verified. This is the demand that can genuinely require completeness — and where an obligation exists, it is a floor set outside the migration, not a preference to trade off. If nobody names a fourth, you have just discovered that most of the history is being kept out of unease rather than use. ## Why history is the expensive half Definitions are text and structure; runs are relationships and provenance, and provenance is what does not travel: - **Time cannot be honestly recreated.** A loaded run happens now, not when it happened. Where a product accepts a supplied date at all, it is a value you asserted rather than a fact it observed. - **People cannot be recreated.** The person who ran it may not exist as an account in the target, and mapping leavers onto a placeholder rewrites the record while appearing to preserve it. - **The surrounding context has to be invented.** A run belongs to something — a grouping the old product created and the new one has no counterpart for — so the load either fabricates containers or drops the association. - **Evidence multiplies the cost.** Files attached to old runs are the bulk of the volume and the part most likely to be skipped, so the loaded history is often the outcomes without the proof. The result is that a full replay is expensive, slow, and *still* lower fidelity than the source it came from. ## Four options, and what each really costs | Option | What you get | What it costs | |---|---|---| | Full replay into the target | History visible where people now work | The highest effort, and provenance you asserted rather than preserved | | Bounded carry (a recent window, or the release still supported) | The queries people actually make are answerable in one place | A visible seam, and the discipline to state where history begins | | Old instance kept read-only | Perfect fidelity, no load work at all | Two systems to reach, and a running cost until the stated end date | | Neutral export to files | Durable, cheap to keep, vendor-independent | Not queryable the way a product is; needs a key and an index to be usable | The fourth deserves more credit than it usually gets. A per-case export of runs and their evidence, keyed by the **old** case identifier and stored where the team already searches, outlives every product involved and costs almost nothing to hold. It is a poor daily tool and an excellent archive. ## How to decide 1. **Count the real queries.** How many times last year did anyone open an execution older than the last couple of releases? Ask, do not guess. 2. **Separate obligation from habit.** Where an external party must be able to see the record, that requirement sets a floor and is decided outside this migration. Everything above the floor is yours to trade. 3. **Price the seam.** A bounded carry means the new product's history starts on a date. That is fine if the date is stated and everyone knows where to look for earlier records — and corrosive if it is discovered. 4. **Check the key exists.** Any archive is worthless without the old case identifier recorded on the migrated cases. If you have not parked the source key during the load, nothing you keep can be found again. 5. **Set the retirement date at the same time.** An old instance kept alive with no end date is the default outcome and the most expensive one. Decide the date while everyone is still paying attention. ## The trap: half-migrated history The worst outcome is a partial load nobody labelled. It looks complete. Reports over it are computed over a subset that reflects what the importer managed rather than what happened, and someone will make a decision on those numbers. A gap you can see is a caveat; a gap you cannot is a lie. So pick an end of the spectrum deliberately. Either the new product's history starts clean at cutover, with the old record preserved somewhere stated, or it is genuinely complete. What must not happen is landing between the two by accident and letting the reporting surface treat the result as whole. ## What good looks like A one-page decision, written down: history in the new product begins at cutover; the old instance stays readable until a named date; before that date a neutral export of runs and evidence, keyed by the old identifier, goes into named storage with a named owner; and anyone needing an older record knows exactly where to go. Written down, that is a decision. Left implicit, it is the thing someone discovers a year later when the old instance has already been switched off.