The history you had before the system did
The company is twenty years old. The tenant is three. Inside the system, that is the difference between a trend and a wall, because what predates go-live usually arrived as profile text, not as transactions anything can aggregate.
◆ Why the history is not thereconversion loads state, not story.
Implementations convert what the new system needs to operate: who works here now, at what pay, in which organization, with service dates as reference fields. Loading twenty years of transactions is expensive and risky, so almost nobody does. Prior careers land as a hire date, free-text notes, maybe a document scan.
The consequence surfaces the first time someone asks for a trend longer than the tenant’s age. Turnover over ten years, growth by division across the merger, pay progression for the veterans: the delivered stores hold three years of month ends on a good day, and nothing before go-live at all. The question is not slow. It is structurally unanswerable inside the tenant, and no future release changes what was never loaded.
◆ What reconstruction islegacy extracts, conformed, stitched at a seam.
The raw material still exists: final extracts from the retired system, payroll registers, the conversion workbooks themselves. Reconstruction is warehouse work in three moves. Land the legacy data as delivered. Conform it to the same dimensions the live model uses, so a department in 2015 rolls up like a department today. Then generate the same monthly snapshot series the owned snapshot produces going forward, back through the legacy years.
| Move | What happens | The discipline |
|---|---|---|
| Land | Legacy extracts stored unchanged in the warehouse’s raw layer. | Never edit the source files. Corrections happen downstream, in code, reviewably. |
| Conform | Legacy people, organizations, and codes mapped onto the live dimensions. | Every mapping is a row in a table, not a decision in someone’s head. |
| Stitch | Legacy snapshots meet live snapshots at one seam date, usually go-live. | The seam is a column, present on every row, so any chart can show it. |
◆ The seam, kept honestrebuilt history labeled as rebuilt, always.
Rebuilt history is a model of the past, not an observation of it. Definitions differed, populations shifted, and some legacy fields simply have no counterpart. The honest reconstruction carries that on its face: a lineage column on every historical row, seam markers on every chart that crosses go-live, and a written register of what could not be rebuilt and why.
-- one trend, the seam explicit SELECT snapshot_month, headcount, history_source -- 'legacy_rebuilt' or 'workday_observed' FROM fct_headcount_monthly ORDER BY snapshot_month
Done this way, the twenty-year chart exists and defends itself. The left side says rebuilt, the right side says observed, the seam says where, and the register says what the rebuild could not know. That is more honesty than the tenant offers about its own window, and it is the difference between a long trend and a long guess. This page ships at the designed maturity stage; the worked example arrives with the synthetic harness.
- go-live
- The date a system starts running the business. History’s cliff edge.
- conversion
- The one-time load that populates a new system from the old one.
- conformed dimension
- A shared dimension both legacy and live data roll up through.
- seam
- The explicit date where rebuilt history meets observed history.
- lineage
- A row’s recorded origin: which source, which rebuild, which rules.
- raw layer
- Where extracts land unchanged, before any transformation.
- register
- The written list of what a rebuild could not recover, and why.
- designed
- This catalog’s first maturity stage: specified and reviewed, not yet run against synthetic data.