Full Calibration History or Active Records Only?

"We have fourteen years in that database. Do we really have to move all of it?"

I hear this question on almost every migration off an aging on-prem calibration system. The person asking is usually a quality or lab manager. They have about 2,400 active instruments, a few thousand retired ones, and something like 180,000 calibration events going back to the first MET/TEAM install. The integrator’s quote is priced on record volume. Someone in IT has already said "just bring the active stuff across", and someone else in quality has answered "the auditor will want the history".

Both of them are partly right. That is why the argument goes round in circles. The way out is to stop treating migration depth as a technical choice or a budget choice. Your record-retention obligations already decide it. You only need to read them.

Why this decision is landing now

If you run MET/TEAM 3.3.0 or 3.3.1, Fluke’s published support schedule lists phone and email support for those versions until December 2026, with no further patches. The 3.4.x line is supported for longer. Upgrading in place is a legitimate, well-documented path, and for a lab that depends on MET/CAL automation it is often the right one. Check the lifecycle notice for your own installation before you plan around any date.

Some teams are choosing instead to move the management and records layer to another system. For them, depth is the first scoping question, and it drives most of the effort. The usual mistake is to answer it last, after the field mapping has already started.

What the standards actually require you to keep

None of the common standards says "migrate everything". None of them says "active records are enough" either. What they say is narrower and more useful:

• ISO/IEC 17025:2017, 7.5 requires technical records that let you repeat the activity, and 7.5.2 requires amendments to stay traceable to the original observations. You cannot "clean up" history on the way across. If you bring a record over, its as-found data, amendments and the person responsible come with it.
• ISO/IEC 17025, 8.4.2 asks you to retain records for a period consistent with your contractual obligations. 7.11 requires the data and information systems you use to be validated, and any changes to them to be authorised, documented and validated before you rely on them. A migrated record is a record your new system now presents as true.
• ISO 9001:2015, 7.1.5.2 requires you to assess whether earlier measurement results were valid when equipment is found unfit. You can only do that if you can still see what the previous calibrations said.
• IATF 16949, 7.1.5.2.1 sets out what calibration/verification records must contain. 7.5.3.2.1 requires records to be kept for as long as the product is active for production and service requirements, plus one calendar year, unless the customer or regulator asks for longer.
• AS9100 and ISO 10012 (7.1.4) say the same thing in their own terms: confirmation records must be kept and retrievable for the defined retention period, which customers often set.

So the real question is not "all or active". It has three parts. How long must the record exist? How far back must it be queryable in daily work? And where may it live during each of those periods? Those three answers become three tiers.

The three-tier model

Tier 1 — Live: every active instrument, fully structured

This is the current state of everything still in service: identity, location, holder, interval, due date, the procedure template it uses, and any limited-calibration restriction. It also includes the calibration events your daily work actually touches. My rule is to bring at least enough events to reach back to the last in-tolerance as-found for each instrument, and never less than two cycles.

The reasoning is practical. When an instrument comes in out of tolerance next March, the impact assessment needs the date it was last known good. If that date is sitting in a system nobody can query, your reverse trace stalls on day one.

Tier 2 — Migrated history: the window you query, not just keep

This is structured history for active instruments, going back as far as you realistically search it. That usually means drift analysis for interval adjustment, customer complaints, and product recalls. For an automotive supplier this window is often set by the longest-running active part number. For a 17025 lab it is often the accreditation cycle plus whatever your contracts state. Write the window down and give the reason for it.

Tier 3 — Validated archive: everything else, read-only

Retired instruments, events older than the Tier 2 window, original certificates as issued, and audit-trail and e-signature history. These go into a frozen, checksummed export that you can open without the legacy application.

That last condition is the one teams skip. Leaving the old database on a server running a version that is no longer supported is not an archive. It is a dependency with no owner.

A worked example

Here is a mid-size lab, using illustrative figures of the kind I’ve seen. It has 2,400 active instruments on mostly annual intervals, 3,100 retired, and 14 years of events. One contract requires ten years of retention. Its longest active customer programme started seven years ago.

• Tier 1: 2,400 instruments, plus events back to the last in-tolerance as-found. That comes to roughly 6,000 events, because a handful of chronic drifters reach back further than two cycles.
• Tier 2: a seven-year window for active instruments, roughly 17,000 events, fully mapped and validated.
• Tier 3: everything else, about 157,000 events plus all retired assets. These are exported once, hashed, sampled against the source, and stored read-only for at least the ten-year contractual period, counted from each record’s date.

As a result, the costly part of the migration (mapping fields, reconciling unit renames and retired procedure versions, validating under 7.11) covers about 13% of the event volume instead of 100%. Nothing is lost, because every record is still retrievable for as long as the retention obligation runs.

The objection: "Storage is cheap. Just move everything."

Storage is cheap. Validation is not.

A fourteen-year calibration database is not consistent with itself. Procedures were revised, tolerance fields were repurposed, units were renamed, a custom field was introduced in year six and abandoned in year nine. Every one of those quirks has to be mapped and then shown to have been mapped correctly before the new system presents those records as authoritative. Bring a 2013 record into a modern schema with a defaulted field, and you have made a record that says something the original never said. An auditor sampling it will find that the record does not match the certificate that was issued, and the problem is no longer about convenience.

The opposite objection, "active only, the rest can stay where it is", fails on the same principle from the other side. A record has to be retrievable for its whole retention period. Retrievable has to mean something that does not depend on software you have stopped maintaining.

What must move regardless of depth

Some attributes are not optional in any tier. They are also the ones most often lost:

| Attribute | Why it cannot be dropped |
|—|—|
| Legacy asset IDs, exactly as printed on labels | Renumbering breaks barcodes and labels on the floor |
| Issued certificate numbers | Customers cite them in FAIRs, PPAPs and their own files |
| Limited-calibration restrictions and certified ranges | Without them, a restricted instrument looks fully usable |
| As-found and as-left values, separately | Needed for impact assessment and interval decisions (17025 7.5) |
| Amendment history and original values | 17025 7.5.2 traceability to original observations |
| E-signature and audit-trail linkage | For Part 11 users, 21 CFR 11.70 requires signatures to stay linked to their records. Archive them together and never re-sign |

Before you sign off the scope: a checklist

• [ ] Every retention obligation listed: contract, customer-specific, regulatory, internal procedure
• [ ] Tier 2 window written down, with the reason (longest active programme, accreditation cycle, recall horizon)
• [ ] Tier 1 rule set: back to last in-tolerance as-found, minimum two cycles
• [ ] Tier 3 format chosen that can be read without the legacy application; checksums recorded
• [ ] Sample comparison of archive against source, documented as part of the 7.11 validation
• [ ] Owner and review date assigned for the archive across its retention period
• [ ] Mandatory attributes from the table above mapped in every tier

Where PrüfDesk fits, and where it does not

PrüfDesk is built to hold Tiers 1 and 2. That covers instrument registration, auto-calculated due dates, pass/fail records with as-found/as-left values and certificates attached, reusable procedure templates that can be overridden per unit, configurable overdue blocking (hard block or soft warning), and a full check-out and possession audit trail. It also produces audit-ready PDF reports and has unlimited users. Pricing is by instrument volume: Starter €49/month for 250 assets, Professional €129/month for 1,000, Enterprise €299/month with no asset limit.

It does not execute automated MET/CAL procedures or drive calibrators. If your bench depends on that automation, it stays where it is, and PrüfDesk sits alongside it as the records layer. The Tier 3 archive is something you own and control by design, whichever system you choose. You should not be dependent on any vendor, us included, to read a certificate you issued in 2014.

If you are working out your tiers and want a second pair of eyes on the retention mapping, talk to us about a migration plan. We will start from your retention policy, not our import template.