Make Your Access Calibration DB Read-Only at Go-Live

"We went live on Monday. On Thursday I found three calibrations logged in Access."

When a migration fails quietly, this is usually how. The extract was clean. Reconciliation balanced. The new system went live, the team was trained, and the go-live email went out. Then a lab technician who has opened the same desktop shortcut every morning for eleven years opened it again, typed in a torque wrench result, and moved on to the next job. The old database took the record without complaint, because nobody had told it to stop.

Migration plans spend weeks on extracting, cleaning and mapping, then give go-live day a single line. That line should say one thing: at cutover, the Access calibration database becomes read-only, and you test that it is.

Why "we told everyone" is not a control

You built the Access database for good reasons. It was free, it ran on every PC, and it let anyone with a shortcut add a record in seconds. On go-live day that last strength becomes the risk. Access has no idea a new system of record exists. If a user can write to the file, the file will keep accepting writes, from whoever, for as long as nobody stops it.

An email cannot remove muscle memory. It also has no effect on things that never read email:

• the desktop shortcut on the shared PC in the gauge crib
• a scheduled task that appends results or emails an overdue list every Monday
• a second Access file, or an Excel workbook, that links to the calibration tables
• a mail-merge template that prints due-date labels from an Access query

Some of these only read from Access. Some write to it. Every one of them has to be found before cutover. Read-only takes care of the writers. The readers are a separate trap, covered below.

A worked example: one record, two truths

Say the final extract runs on Friday at 16:00 and the new system goes live on Monday. On Tuesday a technician calibrates a click torque wrench. The as-found reading is outside tolerance. The wrench is adjusted, and the as-left reading passes. Out of habit, all of this goes into Access.

What the new system shows: the wrench is still in calibration, due next week, with no as-found failure on record. What actually happened: an instrument was found out of tolerance, and under ISO 9001 clause 7.1.5.2 that obliges you to decide whether earlier product verified with it was adversely affected, and to act on that decision. The one record that should start that impact assessment is sitting in a database nobody is watching any more.

Now take the worse version. The as-found result fails, the wrench is tagged for repair, and the failure is logged only in Access. In the new system the wrench is still in calibration, so an operator can check it out from the crib. Overdue blocking cannot help here. The new system can only block an instrument it knows is a problem, and it doesn’t know.

Neither case needs anyone to be careless or dishonest. All it needs is a writable file.

The audit cost comes later and is cumulative. Months on, an auditor working to IATF 16949 or AS9100 picks that wrench and asks for its history. You now have to explain why part of the calibration record lives in one system and part in another, which one is authoritative, and how you know nothing else was split the same way. "We think it was only those three records" is an answer no auditor accepts.

What read-only actually means for an Access file

A banner on the front-end form saying "Archived — do not use" is useful, and you should add one. It is not enough on its own. Read-only has to be enforced where the data lives:

• Split database (front-end and back-end): the tables live in the back-end file, so lock that. Remove write and modify rights on the back-end for every ordinary user and keep one named administrator account with change rights. A front-end on every PC is harmless once its tables can no longer be written to.
• Single-file database: treat the whole file as the back-end. Move it to a share where users have read rights only, or restrict the file itself.
• Stray copies: search local drives and personal folders for copies of the .mdb or .accdb. A desktop copy is a fork waiting to happen. Archive it or delete it with the owner present, and record what you did.
• Other writers: disable or retarget every scheduled job, linked workbook and second database that appends or updates calibration tables.

Then test it with an ordinary user account, not an admin one. Open the database. Try to edit an existing calibration record. Try to add a new one. Both should fail. Then check that a second user can still open the file at the same time, because a lock that turns the archive into a single-user file just creates a different support ticket. Write the test down: date, account used, what was attempted, what happened. That half page is evidence that you controlled the transition, and an auditor will value it more than the go-live email.

Keep a short exception route as well: one named person who can unlock the file temporarily if a genuine correction to a pre-cutover record turns up. Log every use. Better still, make that correction in the new system with a note referencing the legacy record, so the authoritative history stays in one place.

The other half: things that keep reading a frozen file

Read-only stops new writes. It does not stop old outputs. If the Monday overdue report still runs against Access, it will email a list that goes more out of date every week. If label printing still merges from an Access query, a recalibrated thread plug gauge can leave the lab carrying last cycle’s due date. Each of these outputs looks authoritative, and each one is gradually wrong.

So the inventory of downstream consumers is part of the read-only step, not a separate project. For each item, decide whether to repoint it to the new system, replace it with the new system’s equivalent, or retire it. Record who decided and when. Anything that still reads Access after cutover should do so only for a stated historical purpose.

"But we still need the old data"

This is the most common objection, and it actually argues for read-only. Read-only is not deletion. Your legacy records still answer the questions they always did: how this gauge performed in 2019, who signed the certificate, what the as-found reading was before the adjustment. ISO/IEC 17025 labs in particular have retention obligations for technical records, and a frozen file meets them far better than a live one, because nobody can change a frozen record after the fact. Read-only is what lets you trust the archive.

The second objection is "let’s keep both live for a month to be safe." That is not a parallel run. A parallel run happens before go-live, with one system clearly defined as the system of record, and the two are compared on purpose. After go-live, two writable systems is just a split record with no end date.

What the team gets in exchange

Freezing Access is easier to accept when the replacement is better from the first morning. In PrüfDesk, due dates are calculated automatically from each instrument’s interval, so nobody maintains a due-date formula by hand. Overdue blocking can be set per tenant as a hard block or a soft warning, so an overdue pin gauge cannot be quietly checked out of the crib. Every check-out, return and permanent allocation goes into a possession audit trail. Calibration results carry as-found and as-left values and their certificates. Reusable procedure templates mean the technician follows the same steps on every torque wrench of that type. When the auditor asks, the compliance report comes out as a PDF instead of a weekend of reconstruction.

All of that depends on one condition: new records go into the new system and nowhere else.

Go-live read-only checklist

• [ ] Final extract timestamp fixed, with a named owner for any records created after it
• [ ] Back-end (or single file) write rights removed for all ordinary users
• [ ] One named admin account keeps change rights, and every use is logged
• [ ] Local and personal copies of the database found and dealt with
• [ ] Scheduled jobs, linked workbooks and other databases that write to Access disabled
• [ ] Downstream readers (reports, label merges, exports) repointed or retired
• [ ] "Archived — record in the new system" banner on the front-end
• [ ] Read-only tested with an ordinary user account, and the result recorded
• [ ] Concurrent read access confirmed for two users

Before you set the date

If you are planning a cutover for the year-end shutdown, put the read-only step in the plan now, with an owner and a test, rather than finding three stray records the week after. If it helps to see how PrüfDesk handles the new system-of-record side of that day, ask us for a walkthrough on your own instrument types. No commitment, just a look at where your records would live once Access is frozen.