Don’t Stamp Today’s Date on Calibration History

The import finished in about four minutes. Maria, the quality engineer who had carried the Access database on her back for six years, opened the new system to spot-check it and felt her stomach drop. Every one of her 1,180 instruments — the micrometers, the bore gauges, the torque wrenches, all of them — now showed the same last-calibration date: the day she ran the migration. Six years of history, every as-found reading, every interval, every point where a gauge came back out of tolerance and got adjusted, had been flattened into a single Tuesday.

Nothing was technically lost. The old Access file still sat on the server. But the record of truth she was supposed to hand an auditor now said her entire measurement fleet had been calibrated on one day — which is exactly the kind of thing that makes an IATF 16949 auditor stop writing minor findings and start writing major ones.

If you are planning to leave a homegrown calibration database, this is the failure mode to fear the most. Not that the migration fails loudly — that you can see and fix. The danger is that it succeeds quietly and wrong.

Why the dates get overwritten in the first place

This is rarely sabotage. It is a default.

When you export tables out of Access — or worse, out of the Excel workbook bolted onto it — the historical calibration date often lives in a column that is inconsistently formatted, half text and half real dates, with blanks where someone never filled it in. So the import script, or the well-meaning person running it, does the reasonable-looking thing: it maps the fields it can trust and lets the new system set a fresh timestamp for anything it can’t parse. The new system, seeing no clean prior date, records "created today." Every ambiguous record inherits the cutover date.

The result looks tidy. Every instrument has a due date, every row is green, and the dashboard is calm. That surface calm is the trap. A clean-looking database with a fabricated history is more dangerous than a messy one, because no one is alarmed enough to check.

What that one date actually costs you

Three things break at once, and each maps to a clause you will be asked about.

Traceability of the record collapses. ISO 9001 clause 7.1.5.1 requires you to retain documented information as evidence of fitness for purpose, and 7.1.5.2 requires that measuring equipment be calibrated at defined intervals against traceable standards. If every record shares the migration date, you cannot show when an instrument was actually verified or that the interval was ever real. ISO/IEC 17025 labs and AS9100 shops face the same problem with sharper teeth — the whole point of a calibration record is that it is a faithful, time-stamped chain of evidence.

Your due dates become fiction. A calibration management system auto-calculates the next due date from the last calibration plus the interval. Feed it a fake last-calibration date and every future due date is wrong by exactly the gap between the real event and the cutover. An instrument genuinely due next month now reads "due in twelve months." You have not just corrupted the past; you have programmed a fleet of instruments to silently slip overdue, which is the precise risk you were migrating to eliminate.

The as-found / as-left story disappears. The most valuable thing in a mature calibration record is not the pass — it is the history of drift: this bore gauge came back 4 microns high three cycles running, so you shortened its interval. Stamp everything to one date and you lose the sequence. You can no longer defend an interval decision, spot a trending-out-of-tolerance instrument, or reconstruct which parts were measured by a device that was later found bad. That last one — reverse traceability after an out-of-tolerance finding — is exactly what a customer escape investigation demands, and it is where a flattened history hurts most.

"But we still have the old file"

This is the objection I hear every time, and it deserves a straight answer rather than a dismissal. Yes — keeping the read-only Access file is good practice and you should do it. But it does not save you here, for two reasons.

First, it splits your record of truth in two. Your live system says one thing; your archived file says another. An auditor asked to see the calibration history of a specific caliper now watches you open a retired, uncontrolled database to explain away the dates in your current, controlled one. That is not evidence of control; it is evidence you migrated badly. It invites the finding it was meant to avoid.

Second, the old file is frozen the day you stop maintaining it. Every calibration from cutover onward lives only in the new system. Within one cycle you have a permanent seam in your history — everything before the line in one place under old rules, everything after in another — and reconstructing a continuous record for any single instrument means manually stitching two sources across a fake date. History that has to be reassembled by hand is not traceable; it is a research project.

The goal is one continuous, faithful record. Preserve the past inside the new system, and keep the old file as a locked backup you hope never to reopen — not as the half of your history that actually counts.

Migrate the past without rewriting it

Preserving history is not hard. It just has to be a deliberate step instead of an afterthought. The path that works is staged, and you never cut over until it validates.

• Export everything, including the ugly columns. Pull the full history — original calibration dates, as-found and as-left values, results, certificate references — not just the current status snapshot. The messy date column is the one that matters most; do not discard it because it is inconsistent.
• Clean the source dates before you map, not during import. Normalise formats, resolve blanks, and flag genuinely unknown dates explicitly rather than letting the loader silently backfill them. An honestly labelled "date unknown" is defensible; a fabricated date is not.
• Map fields to their real destinations. The historical calibration date maps to the historical calibration date — never to a generic "created" timestamp. A calibration management system like PrüfDesk holds original event dates, as-found/as-left readings, and attached certificates as first-class fields precisely so the chronology survives the move.
• Validate and reconcile before cutover. Reconcile counts and dates against the source: same number of instruments, same intervals, same last-calibration dates, spot-checked against certificates. Keep the reconciliation output — it is your migration evidence, and an auditor loves it.
• Run in parallel for one cycle. Keep both systems live for a calibration cycle so due dates fire correctly in the new one before you trust it alone.

A short pre-migration checklist

• Does the export include original calibration dates, not just current status?
• Are as-found / as-left values and certificate files coming across per record?
• Is every unknown date flagged as unknown rather than backfilled to today?
• Do instrument counts, intervals, and last-cal dates reconcile against the source?
• Is the old database archived read-only, as a backup — not as half your live history?
• Have you run one full cycle in parallel before retiring the old system?

Get those right and the day-one payoff is real: due dates auto-calculate from the true last calibration, overdue status surfaces on its own (with hard-block or soft-warning control per your policy), the full as-found/as-left and possession trail stays intact, and any historical calibration report reprints as an audit-ready PDF that matches what actually happened.

A migration should make your history stronger, not younger. If you are scoping the move off an Access calibration database and want to pressure-test your field mapping before you commit, that is exactly the conversation worth having first — quietly, on a copy, long before the cutover.