ISO 9001 6.3: The Change Record for Leaving Access

Marta runs the calibration program at a Tier 2 stamping plant. Her team spent the summer moving 1,400 instruments out of the Access database a former colleague built in 2011, and the new system went live in September. The IATF surveillance auditor opens the calibration register, sees records created last month, and asks the question Marta didn’t prepare for: "When did you change systems, and where is the change record?"

She has the new system, the export files and a spreadsheet of spot checks. What she doesn’t have is a document that says the change was planned, assessed, approved and verified before the old database stopped being the record. The migration was done well. Nobody can show that it was.

This article is about that gap. Retiring a calibration database is a change to your quality management system, and ISO 9001 expects it to be handled as one. Done properly, the change record is the strongest evidence you’ll have that the migrated history can be trusted.

Why the migration counts as a QMS change

It’s easy to treat the Access database as an IT asset: a file on a share that happens to hold calibration data. It’s more than that. It is where your equipment register lives, where due dates are calculated and where the as-found results sit that prove a gauge was fit for use on the day it measured product. Under ISO 9001 clause 7.1.5, that is retained documented information showing that measuring resources are fit for purpose. AS9100 goes further in 7.1.5.2 and expects a register of monitoring and measuring equipment that names each item, its location, its calibration method, its frequency and its acceptance criteria. In most plants that still run Access, the register is the database.

So replacing it changes how the QMS keeps one of its core records. Clause 6.3 is short: when the organization decides a change to the QMS is needed, the change is carried out in a planned manner, considering four things:

1. the purpose of the change and its potential consequences;
2. the integrity of the quality management system;
3. the availability of resources;
4. the allocation or reallocation of responsibilities and authorities.

Auditors don’t read that as a request for a project plan. They look for evidence: a request, an impact assessment, an approval, the implementation and proof that the result works. "Significant change implemented without impact assessment" is a common finding, and guidance on the clause lists information systems that support the QMS among the typical significant changes. Accredited labs already have a stricter version of the same rule. ISO/IEC 17025 clause 7.11 requires systems that manage laboratory data to be validated before use, and changes to them to be authorized, documented and validated before they are implemented.

What the change record needs to contain

The record doesn’t need to be long. It needs to answer the four considerations of 6.3 with facts about your database. Here is how that looks for a typical Access calibration DB.

Purpose and potential consequences

State why you’re changing. Name the real reasons, not a slogan: the database depends on one person who has left or is about to; the overdue report is a query nobody can explain; records can be edited without a trace; or the platform underneath is changing. Office 2021, including Access 2021, reaches end of support on 13 October 2026, and plenty of IT departments are planning desktop moves right now.

Then state the consequences you considered. This is the part that usually goes missing. For a calibration migration, the consequences that matter are:

• Due dates could shift. If the old system calculated due dates one way and the new one calculates them another way, some instruments will change status on day one. List how many and why.
• History could lose its meaning. A pass/fail result without its as-found reading, tolerance or certificate reference is weaker evidence than the original. Decide which fields carry across and how.
• Instruments could fall out of the register. Homegrown databases often have records the overdue query never sees, such as an instrument with a blank interval or a blank last-calibration date. Access query criteria silently exclude Null values unless someone wrote Is Null into the criteria. Your migration will probably surface these. Record them as a finding of the assessment, not as an embarrassment.
• Two systems could disagree during the parallel run. Decide in writing which one is the record for each record type and date range.

Integrity of the QMS

Show that the QMS keeps working during the change. In practice that means naming the cutover date, the freeze on edits in the legacy database, and what technicians do on the days in between. It also means updating the documents that point at the old system. Your calibration procedure, work instructions and possibly your control plan reference "the gauge database". Those references need a revision, or you’ll have controlled documents describing a system that no longer exists.

Resources

Who does the extract, the cleanup, the mapping and the verification, and how much time do they get? If the only person who understands the VBA is a former employee, say so and state how you’ll close that gap, whether through a documented data map, a few paid hours of their time, or a slower validation.

Responsibilities and authorities

Name the change owner, the approver, the person who signs off the reconciliation and the person who authorizes switching off write access to the legacy file. Clause 6.3 d) is about exactly this. The auditor wants to see that someone had authority over each step, not that "the team" did it.

The evidence that closes the finding before it’s written

The change record is a plan. What makes it convincing is the verification attached to it. Three pieces do most of the work.

A reconciliation report. Compare the counts: instruments in Access against instruments in the new system, calibration events against events, certificates against attachments. Then sample by risk rather than at random. Take every instrument that was overdue or due within 30 days at extract time, every instrument with a failed or adjusted result in the last cycle, and a random set of the rest. For each one, compare the ID, interval, last calibration date, result and due date. File the discrepancies and how you resolved them. A reconciliation with three documented discrepancies is more credible than one that claims zero.

A frozen, read-only copy of the legacy database. Keep the final .accdb or .mdb, compact it, set it to read-only, record a checksum and store it where your retention rules say records live. If an auditor or a customer questions a historical result, you can show the source it came from.

Approval of the result, not only the plan. The record should close with a dated sign-off that the verification passed and the new system is now the record of calibration from a stated date. That one sentence answers Marta’s auditor completely.

An objection worth taking seriously

"This is paperwork for a system nobody ever validated in the first place." That’s true, and it’s why the change record matters. The Access database probably never had a formal validation, and in most audits nobody asked. The migration is the moment the question becomes unavoidable, because the auditor can see a line in the data where the system changed. You can let that line look like a gap, or you can attach a two-page document to it that explains it. The second option costs a few hours and saves you from explaining it under pressure.

The other objection is timing. With Q4 surveillance audits running from October to December, many teams will be mid-parallel-run when the auditor arrives. That’s fine, as long as the change record already exists and says which system is authoritative for what. An open, well-documented change is not a nonconformity. An undocumented one can be.

What changes on day one

Once the change is closed, the new system has to hold up to the same scrutiny. In PrüfDesk, calibration due dates are calculated automatically from the interval and the last result, so there’s no hand-typed due-date field to drift. Pass/fail records carry as-found and as-left values along with the certificate. Reusable procedure templates apply across instruments of the same type and can be overridden per unit. Overdue blocking is configured per tenant as either a hard block or a soft warning. Check-outs and permanent allocations are logged with a full possession trail, and compliance reports come out as audit-ready PDFs. None of that replaces the change record, but it means the history you carried across stays defensible afterwards.

Pre-migration change checklist

• Change request raised, with the purpose stated in plain terms
• Impact assessment covering due-date shifts, field mapping, excluded/Null records and the parallel run
• Controlled documents that reference the old database identified for revision
• Owner, approver and reconciliation signatory named
• Cutover date and legacy edit-freeze date agreed
• Which system is the record, by record type and date range, stated in writing
• Reconciliation method defined: counts, risk-based sample, discrepancy log
• Legacy database archived read-only with a checksum
• Closing sign-off: verification passed, effective date recorded

If you’re planning the move this quarter, World Quality Week (9 to 13 November) is a good moment to announce the change internally, with the record already open. And if you’d like to see how PrüfDesk would hold your migrated calibration history, we’re happy to walk through it with your own instrument list.