Why Overdue Gauges Spike After Leaving Access

Access said 9 overdue. The new system says 61 on day one. Where the gap comes from, and how to brief management before go-live instead of after.

October 12, 2026 8 min read 1,500 words

On Friday, the overdue report from the Access calibration database showed nine instruments. It has shown somewhere between six and twelve every week for as long as anyone can remember. On Monday morning the new system goes live, the dashboard loads, and it says sixty-one.

By ten o’clock the plant manager is at your desk asking the obvious question: did we break something over the weekend?

You didn’t. The sixty-one was already there. Access just never counted it. I have watched this moment play out on more than one migration, and how it goes depends almost entirely on whether management heard the number from you three weeks earlier or from the dashboard that morning.

Why Access reported nine

Your Access database wasn’t lying. It answered exactly the question it was built to answer, and that question was narrower than anyone remembered. Homegrown calibration databases nearly always produce their overdue list from one saved query, written years ago by the person who built the tool. The gap between "what the query checks" and "what is actually overdue" comes from a handful of predictable places.

Blank due dates don’t fail the test, they skip it

A query such as DueDate < Date() compares a date with today. If the due-date field is empty, the comparison doesn’t come back true, so the record is silently left out. Gauges registered in a hurry, transferred from another site, or entered before anyone made the field mandatory never appear on the report. A system that calculates the due date from the last calibration date and the interval will either produce a date or flag that it can’t. In both cases the instrument becomes visible.

Due dates typed by hand never get recalculated

In many Access registers the due date is a field someone types, not a value the database works out. If a micrometer interval was shortened from twelve months to six after an audit finding, the existing due dates stayed exactly where they were. If a calibration was done late but entered with the original due date carried forward, the drift built up quietly. Once due dates are auto-calculated from the actual calibration date and the current interval, every one of those old decisions is applied at once.

The query filtered on status

The overdue query almost always filters on something like Status = "Active". Over the years, instruments marked Spare, In repair, Storage or Missing fell outside that filter. Some of them really are on a shelf. Others went back into use without anyone changing the status, because nothing in the old process tied a check-out to the calibration record. When the new system follows possession, meaning who has the instrument and where it is, those "spares" turn up in someone’s toolbox.

One row, many instruments

A pin-gauge set or a gauge-block set is often stored as a single Access row with one due date. Once the set is migrated as its individual members, which is how most labs actually calibrate and reject them, the instruments that were never sent out with the rest of the set appear on their own.

Reminders depended on a person

If the overdue report had to be run by hand, it was only as complete as the weeks when someone remembered to run it. That is not a data problem, but it explains why nobody noticed the other gaps.

A worked example

Here is an illustrative breakdown for a register of about 1,400 instruments, built from the patterns above. Your numbers will differ, but the categories won’t.

Only five of the sixty-one are "new" in any sense. The rest are records that were always overdue, or always undefined, and nobody could see it. That distinction is what management needs to hear, and it is the reason to classify the number before you present it.

Find the number before go-live

The spike only becomes a crisis when it arrives without warning. During your parallel run, while Access is still the system of record, load the cleaned data into the new system and read its overdue count next to the Access report. Then reconcile the two, line by line, into categories like the table above. This work fits naturally into the reconciliation you should already be doing. It just adds one specific question: for every instrument the new system calls overdue, why did Access not?

Then write a one-page note for management before go-live. Give the honest number, the breakdown, the five or so items that are real misses, and the plan for each category. Present it as what it is: the migration doing its job by finding control gaps that the old tool hid.

Decide what blocking does in week one

If your new system enforces overdue status at check-out, go-live day is when that rule meets sixty-one instruments. PrüfDesk lets each tenant set overdue handling as a hard block or a soft warning. Choose deliberately for go-live week, based on the risk of each instrument, rather than finding out at the first shift change that half the torque wrenches on line 3 won’t check out. Whatever you choose, document it so the choice is defensible later.

The objection: "Aren’t we just generating a nonconformity?"

This is the question that usually stops the conversation, so answer it directly.

The out-of-calibration condition already exists. The migration doesn’t create it, it reveals it. ISO 9001 clause 7.1.5.2 already expects 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 and expects records of that assessment, including the risk to product already shipped. AS9100 and ISO/IEC 17025 take the same position in their own terms. In each case the requirement covers how you respond to the gap, and every one of these frameworks treats self-detection followed by documented action as the system working.

Compare that with the alternative. An auditor samples a gauge from the floor, asks for its calibration status, and finds that the due date is blank or eighteen months old. That becomes a finding, and it is a worse one because your own system didn’t catch it.

There is a quieter version of the same objection: "Can’t we just import the old due dates and clean up afterwards?" You can, and the dashboard on Monday will look calm. But you will have moved the blind spot into a new tool, and you will have to explain later why the new system’s records didn’t match its own calculation on the day you switched. It is better to take the honest number once, while you control the narrative.

What the next few weeks look like

Work the categories, not the total. Recall the in-use "spares" first, because they are the only items with a live product risk. Assign real due dates to the blanks from their last certificates, or calibrate them if no certificate can be found. Send the split-out set members to the lab together. For every instrument that turns out to be out of tolerance when it is calibrated, log the as-found and as-left values and run the impact assessment the standard asks for.

In most migrations I’ve been part of, the count is back to its normal level within one or two calibration cycles. After that, the overdue number on the dashboard is one you can defend, because due dates are calculated, possession is tracked, and the PDF compliance report you hand an auditor shows the same figures as the screen.

Pre-go-live overdue checklist

Run the new system’s overdue count during the parallel run, not after cutover
Reconcile it against the Access report and put every difference into a category
List the instruments with blank or hand-typed due dates
Check "Spare/Storage/Missing" statuses against actual possession
Decide how sets are split into individual members and calibrated
Set hard-block or soft-warning behaviour per tenant for go-live week
Send management a one-page briefing with the honest number and the plan
Prepare impact-assessment records for any item found out of tolerance

A calm Monday

The number on day one is not a verdict on your calibration program. It is the first time the program has been measured with an instrument that can see all of it. If you are planning a migration off Access and want to see how auto-calculated due dates and overdue handling would treat your own register, PrüfDesk is happy to walk through it with you, with your data and at your pace.