Changing the System

Time data has a legal retention obligation and a reporting history. A migration threatens both, in different ways.

What must survive

The statutory record, for the full retention period. This is not optional and it is not satisfied by keeping the old system switched off in a corner that nobody maintains.

The audit trail on that record: creation times, edits, who and when.

Enough of the project attribution to interpret historical cost and effort figures.

The rules in force at the time, or historical records cannot be explained.

The export, tested first

Export before committing to anything.

Check what is actually in it: many systems export the current state and not the edit history, which is the part that matters in a dispute.

Check creation timestamps survive, since a migration that stamps everything with the import date destroys the contemporaneity that made the record credible.

Check completeness against a known period, by reconciling totals.

Where the export is inadequate, keep the old system readable for the retention period rather than migrating a degraded copy and calling it the record.

Archive rather than convert

The safest arrangement for the statutory record: a frozen archive of the old data as exported, unaltered, with its own retention and its own access route.

Converted data in the new system for operational use, clearly marked as imported.

Do not overwrite the archive with corrections, because its value is that it is what was recorded at the time.

The reporting break

Category structures rarely map cleanly.

Map old to new explicitly and keep the mapping, or every year-on-year comparison becomes uninterpretable.

Where a category genuinely has no equivalent, say so rather than forcing it into the nearest one.

Mark the break on every trend chart, so nobody reads a structural change as an operational one.

Expect a step in several measures at the migration date, and annotate it.

The people side

A new system resets the habits that took a year to establish.

Recording delay will worsen for a period; measure it so you know when it recovers.

Consult again if the new system does anything the old one did not, particularly if it has monitoring features the old one lacked.

Check the defaults on the new product, which is where monitoring arrives unnoticed during a migration that nobody framed as a policy change.

Running both

A parallel period is tempting and expensive. Double entry produces worse data in both systems.

Prefer a clean cutover at a period boundary, with the old system readable.

If parallel running is unavoidable, keep it short and name which is authoritative, because two records that disagree are worse than one.

What to verify afterwards

Totals reconcile for a sample period.

A worker can see their historical record, which is part of the standard.

Retention is configured on the archive, not just on the new system.

A sample entry can be traced end to end through the migration.

The edit history is intact for anything within the dispute window.

Testing the export first

Before committing to any migration, find out what actually comes out.

Export a known period from the old system.

Check the edit history survives, since many exports carry the current state only — and the history is the part that matters in a dispute.

Check creation timestamps are preserved rather than stamped with the import date.

Reconcile totals against a report from the old system.

Where the export is inadequate, keep the old system readable rather than migrating a degraded copy and calling it the statutory record.

Consulting again

The step most often skipped during a system change.

A new product may do things the old one did not, particularly if it has capture features the old one lacked.

Which makes it a new deployment for consultation purposes, not a technical upgrade.

Check the defaults on the new product before anyone logs in.

Say what changes and what does not, including that the purpose limitation carries over.

A migration is where monitoring most often arrives unnoticed, because nobody framed it as a policy decision.

Check the difficult case

Use this migration reference to frame one representative test for this issue. The useful evidence is not the marketing description itself but the record created when a worker corrects an entry, a manager reviews it and an administrator exports it.