Switching off an old validated system feels like an IT job. It isn't. The records it holds still carry retention obligations, an inspector can still ask for them, and "that system was retired" is not an answer.
Done properly, decommissioning removes a real maintenance burden — one fewer periodic review, access review, supplier relationship and patching obligation, forever. Done badly, it creates a gap you discover years later.
Decide what happens to the records first
Nothing else can be planned until this is settled. For each record type the system holds, decide and document one of:
- Migrate to the replacement system — see validating a data migration.
- Archive in a readable, non-proprietary format with its metadata and audit trail alongside.
- Retain in place by keeping the system running read-only — the most expensive option, and the one chosen by default when nobody decides.
- Dispose, where retention has genuinely expired, with an approved rationale.
Retention runs from a defined event, not from the shutdown date — see GxP archiving and data retention. Get that wrong and you will dispose of something you still needed.
Prove the records are still usable
An archive you cannot read is not retention. Before shutdown, demonstrate and document a retrieval: pick a record, retrieve it from the archive, and confirm it is complete, legible and attributable — with its audit trail and the meaning of any signatures intact.
Two traps. A proprietary export that only the retired application can open is not an archive. And a PDF of a record without its audit trail has lost the evidence that made it trustworthy — it may still satisfy a business need, but be explicit that this is what you chose and why.
Repeat the retrieval test periodically afterwards. Formats and readers age; nobody notices until the request arrives.
The decommissioning package
- A decommissioning plan, approved before anything is switched off: scope, record disposition per type, verification approach, timing, rollback.
- Change control — retirement is a change, assessed for GxP impact like any other.
- Evidence of record disposition: migration reconciliation, archive verification, or the disposal approval.
- A retrieval test record proving the archive works.
- Access termination and data sanitisation for the decommissioned infrastructure.
- SOP and inventory updates so procedures stop referring to a system that no longer exists.
- A summary report closing it out, approved by QA and the system owner. See roles and responsibilities.
Half-retired systems
The common failure is not a bad decommissioning — it is the absence of one. The system stops being used, nobody formally retires it, and it sits there: still installed, still holding records, still nominally in the inventory, with no owner and no periodic review.
That is worse than either extreme. It carries all the obligations of a live system and none of the attention. An inspector who finds one will reasonably ask what else is unmanaged.
A simple check: go through your system inventory and mark anything with no active users in the last year. Each one is either genuinely needed — in which case give it an owner and a review — or it should be retired properly. Both outcomes are fine; the middle is not.
For the wider estate problem, see legacy validated estates and GxP software.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.