We're not just migrating files, we're migrating the document trail.
"We're not just migrating files, we're migrating the document trail."
That's what the quality admin said at kick-off. Then the second half: "If it's not possible, then we lose everything we've done."
The customer was a specialist envelope contractor in England. Rainscreen, insulation, fire stopping, mostly on higher-risk buildings under the Building Safety Act. They were leaving their CDE under a break notice, with over a hundred projects, about 2 TB, roughly 800,000 files and 30,000 forms. Moving the files themselves was the easy part.
What's actually in a "document trail"?
The old CDE kept four histories for every document:
- revision history: which version, when, by whom
- status history: every change from work in progress → shared → published
- distribution history: who it was sent to, and when
- access history: every view and every download, by every person
Most systems can carry the first two, because a revision is a revision and a status is just a field.
The other two were the problem. The new system had no place to store "who downloaded this drawing two years ago". It logs its own access from the day you start using it, and it has no way to show what happened in the old system over the last five years.
So everyone kept asking "can we import the audit trail?", and the honest answer was "partly, and the part we can't import is the part you care about".
Why does it break?
Trace one drawing through the move:
Drawing created in the old CDE → revised three times → issued to the fire stopping subbie → opened by the site manager on the morning of the install → exported → arrives in the new system with its latest revision and status, and nothing else.
You keep the file and lose everything that happened to it. On a higher-risk building that history is what people look for when something goes wrong: did the installer see revision C before they started?
It's like moving flat. The removal company carries every box, every chair, the washing machine. Nobody packs the drawer with the receipts and warranty cards, because it was "not in scope", and you only notice when the washing machine breaks.
Where did it nearly go wrong?
Mostly in the expectations, less in the data.
Nobody had tested the new system against their own way of working before they decided to migrate. So every difference between old and new turned up as a surprise, and every surprise landed on our desk. That included work that was scoped on their side, and sometimes a request to change the software just for them.
What would losing it cost?
In England, the Building Safety Act requires the client, principal designer and principal contractor on a higher-risk building project to keep a golden thread: a digital record of the building's information that is secure, accessible and accurate (gov.uk). At Gateway 3 the Building Safety Regulator decides whether the building can be occupied at all. And since the Act amended the Defective Premises Act, claims can reach back 15 years, or 30 for older work (Reed Smith).
So we weren't counting the cost in hours. A missing access log can be the only evidence of who saw which revision before they built, and someone might ask for it in 2041.
You also can't rebuild it later. One project alone held over 11,000 per-document audit events, nearly 1,000 project-access events and about 19,000 folder-permission events. That data exists only in the source system. When the contract ends it's gone, and the contractor can no longer show compliance on any of the higher-risk projects it worked on. That was over a hundred projects.
What did we do?
- Asked a different question: where does history land when the new system has no native place for it?
- Made the outgoing vendor itemise what they export. It took about three rounds of written questions before all four histories were confirmed as CSV exports. Their first answer was "full audit history included", which told us nothing about what was actually in it.
- Validated a sample archive before trusting it. That's where the counts above came from.
- Split the history in two. The new system holds revisions and status natively, plus a read-only history field on tickets. Distribution and access get archived as evidence: per-folder "history register" PDFs (53 on one project, 76 on the next), with the raw CSVs kept next to them.
Getting access history out as CSV was what de-risked the engagement more than anything else.
The history inventory (copy this)
| History | What it proves | Native home in the new system? | If not, where it lands | Confirmed in writing? |
|---|---|---|---|---|
| Revision | Which version existed when | Usually yes | n/a | ☐ |
| Status | When it was approved for use | Usually yes | Read-only field | ☐ |
| Distribution | Who was sent it | Often no | History register PDF + CSV | ☐ |
| Access | Who opened or downloaded it | Almost never | History register PDF + CSV | ☐ |
And before anyone signs a break notice:
- has someone tested the new system with one real project, end to end?
- which histories does the old vendor export, itemised, in writing?
- in what format, and has anyone actually opened a sample?
- whose job is each scope item, written down?
- (would you add another one?)
Then you know if you're moving house, or moving the evidence.
What to take away
"Migrate the audit trail" is a compliance requirement, and you can't treat it as one data type. Split it into what the new system logs natively and what you archive as evidence, and get the old vendor to list every history type in writing before you rely on their sales answer.
Which of your CDE's histories would you lose if the contract ended next month?