An As-Found Failure in Cutover Week: Reverse Traceability When the History Lives in Two Systems

"Which wrenches did we calibrate on that analyser since July, and where did they go?" That is the question your quality manager will ask the morning an as-found result comes back out of tolerance. On an ordinary day it’s one query. In the weeks after you move your calibration records off an aging on-prem system, it can turn into two queries, two sets of IDs, two clocks and an argument about which one is authoritative.

This article covers that one scenario. It isn’t about whether to upgrade or migrate, and it isn’t a general out-of-tolerance playbook. It’s about what you need to set up before cutover so that a reverse trace whose suspect window crosses the cutover date still runs as one clean, defensible investigation.

The scenario, with dates

Take an automotive supplier running Fluke MET/TEAM 3.3.x. Fluke’s published support schedule lists phone and email support for 3.3.0 and 3.3.1 as ending in December 2026, and patch development for those versions has already stopped. (Read the schedule yourself and check your vendor’s lifecycle notice for your exact build, because this kind of detail gets repeated wrongly.) The plant chooses to move its calibration management and records layer to a new system over the year-end shutdown. Go-live is 4 January 2027.

On 11 January, the plant’s reference torque analyser comes back from its accredited external calibration. On the 20 N·m range, the as-found result is outside tolerance. The last good calibration was on 12 July 2026.

That puts the suspect window at 12 July 2026 to 11 January 2027. About 25 weeks of it sit in MET/TEAM and one week sits in the new system. Every click torque wrench verified on that analyser during the window is now suspect, and so is every joint those wrenches tightened.

The arithmetic is the part most migration plans miss. This isn’t a cutover-week edge case. Any out-of-tolerance finding on a standard or gauge in the first calibration interval after go-live will have a suspect window that starts in the old system. If your intervals are 12 months, every as-found failure you record in 2027 crosses the boundary. You won’t be running this investigation once. You’ll be running it all year.

What the standards require you to produce

The requirement is the same in each framework:

• ISO 9001 7.1.5.2 requires you to determine whether the validity of previous measurement results has been adversely affected when equipment is found unfit for its intended purpose, and to take appropriate action.
• IATF 16949 7.1.5.2.1 goes further. The calibration record has to include the as-received out-of-specification readings, an assessment of the risk to the intended use, and the action taken. If suspect product or material has shipped, it requires notification of the customer.
• AS9100 and ISO 10012 have equivalent expectations about evaluating the validity of prior results.
• For an accredited lab, ISO/IEC 17025 7.5 requires technical records detailed enough to identify the factors affecting a result, which includes the equipment used. 7.11 requires that the system holding those records is validated before use and that its data keeps its integrity.

None of these documents makes an exception for a migration in progress. "Half the history is in the old database" isn’t a finding an auditor will accept, but "we couldn’t reconstruct which wrenches were affected" is one they will write up.

Why a split history breaks the trace

A reverse trace has two hops:

1. Standard to instruments. Which instruments were calibrated or verified using the failed standard during the window?
2. Instruments to use. Where were those instruments, who had them, and what did they measure or tighten while they relied on the suspect calibration?

Across a cutover, each hop can fail in its own way.

Identifiers drift. If asset IDs were cleaned up during migration (prefixes removed, duplicates merged, a new numbering scheme), "TW-0412" in the legacy database and "TQ-412" in the new one have to be joined by a map that someone kept.

"Standards used" may not have migrated as a link. If your MET/TEAM database records the standards used against each calibration result (check that it does for yours), that association may come across as free text, as an attachment, or not at all. A verdict and a certificate PDF migrate easily. A queryable relationship between a calibration event and the reference standard used for it often doesn’t.

Possession history is shaped differently. Legacy location and check-out data, including MET/TEAM’s check-out-and-synchronise pattern for field work, won’t map one-to-one onto a new system’s allocation and booking model. The gap you need to worry about is the instrument that was checked out on 30 December and checked in on 5 January.

Clocks and time zones. A server-local timestamp in one system and UTC in the other can put a borderline event on the wrong side of the window.

The legacy system is the system you’re decommissioning. If the old SQL Server has been switched off and nobody can query it without IT spending a day restoring a backup, your containment clock is running while you wait.

The tool: a cross-cutover reverse-trace crosswalk

Build this before go-live, not after the first failure.

| Trace question | Pre-cutover source | Post-cutover source | Join key | Owner |
|—|—|—|—|—|
| Which instruments were calibrated with standard X between dates A and B? | Saved, version-controlled query against the read-only legacy database | Calibration records in the new system, filtered by reference-standard ID | Standard ID via ID map | Quality engineer |
| Which certificates and as-found/as-left values are affected? | Legacy result tables plus exported certificates, with checksums | Records and certificates in the new system | Instrument ID plus calibration date | Lab lead |
| Who had each suspect instrument, where, and when? | Legacy location/check-out history | Check-out and allocation audit trail | Instrument ID via ID map | Department manager |
| Which product, lots or work orders did it touch? | MES / production records (outside both systems) | Same | Station, date, operator | Production quality |

Four rules go with the table.

1. Freeze, don’t kill, the legacy database

Keep it read-only and queryable for at least your retention period. IATF 16949 7.5.3.2.1 ties retention for many records to product-active life plus one calendar year unless a customer or regulator specifies otherwise. Save the reverse-trace query itself as a controlled document, written and tested now, while people who know the schema are still around. Your vendor’s direct support for 3.3.x schema questions is time-limited too.

2. Keep the ID map as a record

Treat the legacy-to-new identifier map as a controlled record with a checksum, not as a migration script’s leftover CSV. Without it, the trace can’t make the first join.

3. Capture the reference standard on every new record from day one

Whatever system you move to, every calibration logged after go-live should identify the standard used. In PrüfDesk, the practical way to do that is a step in the reusable procedure template for that equipment type (overridable per unit where needed), so the technician can’t close the record without entering it. If the step isn’t in the template on 4 January, the post-cutover week of your trace is guesswork.

4. Rehearse the trace as part of validation

Pick a real standard at random before go-live. Run the full two-hop trace across a synthetic window that straddles the planned cutover date, and record how long it took and what it returned. That rehearsal is the most convincing piece of 17025 7.11 validation evidence you can show an assessor, because it tests the outcome the records exist to support.

The objection: "We’ll migrate full history, so it’s all in one place"

Migrating complete history is often the right call. It doesn’t remove the need for the crosswalk, for three reasons. Relationships such as standards used and possession events are the parts most likely to migrate imperfectly. The legacy database stays the original record of anything created in it, so an auditor may still ask you to show the source. And until you’ve rehearsed the trace, you don’t know whether the migrated history answers the question or only contains the data.

A second objection is "this is rare." For one standard in one week, yes. Summed across every standard and gauge over the first interval after go-live, it’s close to certain to happen.

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

PrüfDesk replaces the calibration management and records layer. That covers instrument registration, auto-calculated due dates, pass/fail and as-found/as-left records with certificates, reusable procedure templates, configurable overdue blocking (hard block or soft warning), check-out and allocation tracking with a full possession audit trail, and audit-ready PDF reports, with unlimited users. Its possession trail answers hop two for everything after go-live. Overdue blocking can stop a quarantined wrench from being checked out while the investigation runs.

It does not execute automated MET/CAL procedures or drive calibrators. If MET/CAL automation is central to your bench work, you’ll keep it or replace it on its own terms.

Public plans are Starter €49/month (250 assets), Professional €129/month (1,000 assets) and Enterprise €299/month (unlimited assets), all with unlimited users.

If a cutover is on your calendar for the shutdown, talk to us about a migration plan. We’ll start with the crosswalk table above and your hardest-to-trace standard.