Keep the Test Points, Not Just the Verdict, When You Migrate

"We’ll migrate the instruments, the due dates and the pass/fail history. The certificates come across as PDFs. That’s everything, isn’t it?"

I’ve heard some version of that sentence in almost every migration kick-off I’ve been part of, and I said it myself the first time I moved a lab off a legacy on-prem system. It sounds complete. The instrument register is there, every instrument has its last result and its next due date, and the certificates are attached. On a dashboard, nothing is missing.

What’s missing is the measurement. If you run Fluke MET/TEAM with MET/CAL, the system has spent years recording far more than a verdict. For every calibration it holds a result set: each test point, its nominal, the reading, the limits applied, often an as-found and an as-left value, and the uncertainty. That point-level data is where most of a calibration record’s evidential value sits. Many migrations quietly leave it behind.

This is relevant now because Fluke’s published MET/TEAM support schedule lists phone and email support for 3.3.0 and 3.3.1 as ending in December 2026, with no further patches. Check your own vendor lifecycle notice for the exact date that applies to you. Whether you upgrade in place or move the records layer somewhere else, the data question is identical: what exactly are you keeping?

A worked example: one torque wrench, three cycles

Say you have a 20–100 N·m click torque wrench, checked at 20%, 60% and 100% of range against a ±4% tolerance. Here is its history as the summary layer stores it:

| Cycle | Verdict |
|—|—|
| 2024 | PASS |
| 2025 | PASS |
| 2026 | PASS |

Here is the same history with the as-found deviation at the 100 N·m point:

| Cycle | As-found at 100 N·m | Tolerance |
|—|—|—|
| 2024 | +0.4% | ±4% |
| 2025 | +1.2% | ±4% |
| 2026 | +3.6% | ±4% |

The first table says the wrench is fine. The second shows a wrench drifting steadily toward its upper limit, which will probably fail as-found at the next cycle. The first table supports keeping the 12-month interval. The second argues for shortening it, or at least for watching that point closely. Both tables describe the same instrument. Only one of them lets you make a technical decision.

Calibration-interval guidance such as ILAC-G24 / OIML D10 rests on exactly this kind of evidence: how instruments actually behave from one cycle to the next. A row of verdicts can only tell you how many times an instrument passed. It can’t tell you how close it came to failing.

The out-of-tolerance case is worse

Now suppose the 2026 result had been +4.3% as-found at 100 N·m and inside tolerance at 20% and 60%. That is a nonconformance, and the question that follows is always the same: what did we make with this tool, and does any of it need to be recalled or re-checked?

With point-level data, the impact assessment can be narrow. The error showed up at the top of the range, so the exposure is joints tightened close to 100 N·m since the last good calibration. With only a FAIL flag, the honest answer is "everything this wrench touched." For an IATF 16949 supplier, 7.1.5.2 requires an assessment of the validity of previous measurement results when equipment is found out of calibration. ISO 9001 7.1.5.2 contains the same obligation. The test points are what make that assessment proportionate and not a blanket recall.

What "the result set" actually means: a field inventory

Before you write a mapping, list what a complete point-level record contains in your current system. Ask your vendor to confirm the export path for full result sets. If you are on 3.3.x, do that while phone and email support is still available. This is the minimum I would expect to survive the move:

• Test point identity and order: which point, in which sequence, under which procedure.
• Nominal value and unit.
• As-found reading and as-left reading per point, where adjustment was performed.
• Limits as applied at the time: the actual lower and upper limits used that day, not the ones in today’s procedure.
• Per-point pass/fail.
• Measurement uncertainty per point, or a reference to the budget used.
• Reference standards used, with their own calibration status at the time.
• Procedure name and revision, technician, date, and environmental conditions where they were recorded.

The "limits as applied" line is where migrations fail most quietly. If your mapping re-derives tolerances from the current procedure template, a historical result can silently change from PASS to FAIL, or worse, from FAIL to PASS. Historical records must carry their historical limits.

The objection: "The certificate PDF already shows the points"

Often it does, and you should certainly keep it. But a PDF is a rendering of data, not the data. It works as evidence for one event. You can’t trend from it. Plotting drift for 400 instruments over eight years from PDFs means someone retyping numbers, which is exactly the kind of manual data transfer ISO/IEC 17025 7.11.6 asks you to check. And for in-house calibrations there may be no external certificate at all. The result set inside your system may be the only primary record that exists.

The second objection is volume. Not every point from 1998 needs to become structured data in the new system. A defensible, documented split looks like this:

• Structured, point-level: active instruments and reference standards, for at least the cycles you use for interval decisions and impact assessments.
• Archived, intact: older history kept as the original export plus certificates, checksummed, readable, and retained under your 8.4 records controls.

That is a decision you write down and justify, not one you make by omission.

Proving the points arrived intact

ISO/IEC 17025 7.11.2 requires that changes to a laboratory information management system are validated before implementation, and 7.11.6 requires that data transfers are checked. ISO 13008:2022 frames the goal as keeping digital records authentic, reliable, intact and usable through a migration. For point-level data, a practical verification looks like this:

1. Freeze and fingerprint. Export the result sets, store an untouched copy, and record a SHA-256 checksum for each file.
2. Reconcile counts. Compare records per instrument and points per record between the source and target. The difference should be zero or explained.
3. Recompute verdicts. For a documented sample that over-weights failures, adjustments and reference standards, recompute per-point pass/fail from the migrated nominal, reading and historical limits. It must match the original verdict.
4. Spot-check against certificates. Trace a sample of migrated points back to the signed certificate or source report.
5. File the evidence. Sample, discrepancies, resolutions and sign-off go into the validation record. That record is what your assessor will ask for.

Where PrüfDesk fits, and where it doesn’t

PrüfDesk replaces the calibration management and records layer. Each calibration record holds step-level measured values against procedure template steps that carry their own tolerances, per-point measurement uncertainty, as-found and as-left values, the reference standards used, and the certificate. Templates are reusable across an instrument type and can be overridden per unit. Due dates are calculated automatically, overdue instruments can be hard-blocked or soft-warned, and audit-ready PDF reports draw on the same data.

It does not execute MET/CAL procedures or drive calibrators. If MET/CAL automation is central to your bench work, that capability stays where it is, and it is excellent at it. And if your result sets carry structures your new records layer must reproduce exactly, such as paired as-found/as-left at every point, multiple runs, or custom limit logic, prove that on a sample of your own records in a pilot before you commit. Don’t take a vendor’s word for it, including ours.

Plans are priced by instrument count with unlimited users: Starter €49/month (250 assets), Professional €129/month (1,000 assets), Enterprise €299/month (unlimited).

If you’re deciding this quarter, talk to us about a migration plan. Bring one exported result set and we’ll walk through the point-level mapping with you.