Skip to content
Upgrade or Migrate? ISO 17025 7.11 Validation Either Way

Upgrade or Migrate? ISO 17025 7.11 Validation Either Way

A MET/TEAM 3.3 upgrade and a migration both need ISO/IEC 17025 7.11 validation. Compare the two packages side by side before budget close.

8 min read 1,407 words

"The upgrade is the safe option. Same vendor, same database, we just install it over Christmas." I hear some version of this from almost every lab manager running MET/TEAM 3.3.x this autumn. The budget for 2027 closes in a few weeks, the surveillance visit is booked for February, and the reasoning is that an in-place upgrade means less to prove to the assessor than a move to another system.

I understand why people believe that, and it’s wrong. Under ISO/IEC 17025:2017 both options are a change to your laboratory information management system, and clause 7.11.2 asks for the same thing in both cases: the change has to be authorised, documented and validated before it goes live. The useful comparison is between the two validation packages, because each one has its own cost, its own unknowns and its own failure modes.

Why the question is on your desk now

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. Patches and new features for those versions have already stopped. The currently supported line, 3.4.0, is listed with support until December 2028. Fluke gives the month, not the day, so check your vendor’s lifecycle notice and your support contract for the exact date and terms.

Nothing in that schedule is a criticism of the product. MET/TEAM with MET/CAL is a mature, well-regarded platform, and its procedure automation is excellent. You’re making a lifecycle decision, and an assessor will expect to see that decision handled as a controlled change.

A dry-block temperature calibrator with reference probes beside a laptop showing a calibration dashboard, an older server tower out of focus behind

What 7.11 actually asks, whichever path you take

Three clauses carry most of the weight:

  • 7.11.2. The LIMS must be validated for functionality before it is introduced. Changes, including laboratory configuration or modifications to commercial off-the-shelf software, must be authorised, documented and validated before they are implemented. A vendor upgrade counts as a modification. Shipping from the same vendor doesn’t exempt it.
  • 7.11.6. Calculations and data transfers must be checked in an appropriate and systematic manner. An upgrade touches calculations because it changes the schema, reports and client components. A migration touches data transfer by definition. Both touch both.
  • 8.4.2 together with 7.5. Technical records must stay retrievable and legible, and they must keep the original observations and the identity of whoever did the work. That’s true for an upgraded database and for a migrated one.

The Italian guidance document ASSOTIC TR 01/2024 on digitalised systems in 17025 laboratories states it directly: a validation plan should cover "verification of the data migration (if applicable)". For data conversion it points to ISO 13008:2022, which describes migration in terms of preserving the authenticity, reliability, integrity and usability of records as evidence. Those four properties make good acceptance criteria for either package.

The same reasoning applies outside 17025. ISO 9001 7.1.5 and IATF 16949 7.1.5.2 require retained evidence that monitoring and measuring resources are fit for purpose and that calibration records are maintained, and AS9100 and ISO 10012 add expectations about recall and traceability. If your records system changes, your evidence that those records are still intact has to come through the change with them.

The two validation packages, side by side

Most of the work is common to both. Where they differ, they differ a lot.

| Validation element | In-place upgrade (3.3.x → 3.4.x) | Migrate the records layer |
|—|—|—|
| Change authorisation and risk assessment | Required | Required |
| Test environment | A restored copy of production. Fluke’s 3.4.0 README warns "the update cannot be reverted", so you can’t test on live data | The new system with a trial import |
| Calculation verification (7.11.6) | Re-run known records through the upgraded MET/CAL client and reports; check pass/fail limits and uncertainties | Check that due dates recalculate correctly from migrated intervals and last-calibration dates |
| Data-transfer verification (7.11.6) | Usually limited: record counts and spot checks before and after the upgrade | The heaviest item: counts, file checksums, field mapping, point-level samples |
| Reports and certificates | Custom Crystal reports re-tested after redeployment | Certificate PDFs carried as attachments and checksummed; new report templates validated |
| Configuration traps | System Default numeric values in en-US format (the README warns of calculation errors otherwise); licence re-registration; Mobile workstations checked in first | Mapping status codes, intervals and overdue policy into the new configuration |
| New functionality | E-signatures on work orders and Part 11 auditing in 3.4.0, which need validating if you switch them on | Every configured workflow you’ll rely on |
| Procedure execution | Unchanged: MET/CAL keeps running your procedures | Out of scope for a records-only system. Decide how automated results reach the new records |
| Legacy archive (8.4.2) | Same database, so less to do | The read-only archive of the old system must stay retrievable |

Look at the last two rows of the migration column and you’ll see the strongest case for upgrading. If your lab depends on automated MET/CAL procedures driving calibrators, a migration of the management layer doesn’t remove that dependency. You’d still need a validated route for those results into the new records. That’s a real cost, and I’d rather you weighed it now than found it in January.

Stainless-steel reference weights in a graded row on a granite weighing table beside an analytical balance

A worked example

Take a 17025-accredited lab with about 1,400 instruments under management: mostly dimensional, pressure and temperature, with a smaller mass bench. Two technicians run MET/CAL procedures on electrical work, and everything else is calibrated manually against templates. The surveillance visit is in February.

If they upgrade, the validation package looks roughly like this. Restore a copy of production. Apply 3.4.x to the copy, including the separate SQL Server, NI-488.2/NI-VISA and client installers the README calls for. Pick a stratified sample of about 30 historical records across disciplines and re-open them in the upgraded system. Re-run the 5 custom certificate reports and compare them field by field with the originals. Confirm the numeric locale settings. Check every Mobile workstation in. Repeat the whole thing on production during shutdown. Most of the unknowns are technical, and the vendor knows the answers to most of them.

If they migrate the records layer, the package changes shape. Export everything and keep an untouched copy. Reconcile record counts per instrument class. Checksum every certificate file before and after transfer. For the same 30-record sample, compare point-level as-found and as-left values against the source, and don’t settle for checking only the pass/fail verdict. Confirm that every migrated due date equals last calibration plus interval. Configure the overdue policy so it is at least as strict as the old recall control. Keep the old database as a validated read-only archive. Because the electrical bench still runs MET/CAL, the lab also has to document how those results are recorded. Most of these unknowns sit in the data, and the lab knows its own data better than any vendor does.

Both packages are a few weeks of disciplined work, and neither one is trivial. Choose the one whose unknowns you’re better placed to resolve before February.

A thread plug gauge with GO and NO-GO ends and a thread ring gauge on a granite surface plate, a laptop comparing two record sets behind

The objection: "Our assessor has never asked about software validation"

That may be true so far. A version that has just left vendor support is the kind of change a good assessor notices, though, and the first visit after it is usually where the question gets asked. Whichever path you choose, a validation record you can show will save you a long conversation. One you have to reconstruct afterwards won’t.

A checklist for this quarter

  • Raise the change request now and name the owner, even if the decision is still open.
  • While 3.3.x phone and email support is still available, get written vendor answers on schema changes, attachment storage and how result sets export.
  • Write acceptance criteria against ISO 13008’s four properties: authenticity, reliability, integrity, usability.
  • Choose your 30-record sample now, across disciplines and including point-level data.
  • Decide what happens to automated procedure results under each path.
  • Book the validation work before the shutdown window, not inside it.

Where PrüfDesk fits

PrüfDesk replaces the calibration management and records layer. That covers instrument registration, auto-calculated due dates, as-found/as-left records with certificates, reusable procedure templates you can override per unit, overdue blocking set to hard-block or soft-warning, check-out with a full possession audit trail, and audit-ready PDF reports, all with unlimited users. It does not execute automated MET/CAL procedures or drive calibrators. Public plans are Starter €49/month for 250 assets, Professional €129/month for 1,000 and Enterprise €299/month with no asset limit. The example lab above would be on Enterprise.

If the migration package looks like the better fit for your lab, talk to us about a migration plan. If the upgrade package does, that’s a sound decision too. Just validate it before you install it.