System Decommissioning, Data Archival, and Lawful Retention

A validated system reaches end of life. The vendor stops supporting the version, the platform moves to a successor, the contract with the cloud provider lapses, or the process the system supported is shut down. At that point the running application stops being the asset. The data it holds becomes the asset, and that data often has to outlive the system that created it by a decade or more. Decommissioning is the discipline of taking a system out of service without losing, corrupting, or stranding the records that still carry regulatory weight. Done well, it is invisible: years later, an inspector asks for a batch record from a system retired in 2021 and you produce it, complete with its audit trail, inside an hour. Done badly, it is a category of finding that is hard to remediate after the fact, because the original system is gone and you cannot go back and capture what you failed to capture.

This article covers retention determination, the migrate-versus-archive decision, building an archive that stays readable for the full retention period, preserving the audit trail and metadata that make a record trustworthy, periodic retrievability testing, the certificate of destruction, and legal hold. It draws a hard line between decommissioning and backup or disaster recovery, because the two get confused and the confusion produces real gaps. If you are coming to this cold, the data lifecycle and metadata frames where archival sits in a record’s life, and backup, restore, and disaster recovery validation covers the availability controls that decommissioning is often mistaken for.

Decommissioning Is Not Backup or Disaster Recovery

Start here, because conflating these three is the root of a surprising number of problems.

Backup and disaster recovery protect availability of a running system. A backup is a copy taken so that if the live system fails, you can restore it and keep operating. Its horizon is short, typically days to a few months of retained sets, and its success criterion is “the system comes back”. The data inside is still owned and served by the live application.

Archival for decommissioning protects the record itself after the application that produced it is gone. Its horizon is the full regulatory retention period, which can run many years past the point where the source system no longer exists. Its success criterion is “a human can still read the record, with its audit trail and metadata, and prove it is complete and unaltered, long after nobody can run the original software”.

The two failure modes are different, and that is the point. A backup of a decommissioned system is a trap. You can hold a database backup file for fifteen years, but if the application that interprets that database is gone, the backup is an undecipherable blob. You technically “kept the data” and cannot read a single record. Restoring it would mean rebuilding the original application stack, including an operating system and database engine that are themselves obsolete and unsupported. That is not retention; it is a liability you have not noticed yet.

A third verb belongs in the same comparison, because it gets confused with the other two just as often: migration. Migration is neither restoring a system nor preserving a record independent of any application; it is moving the record into a different, currently supported application that takes over ownership of it going forward.

Migration answers a different question than either of the other two: not “how do we keep this record safe” but “where does this record live going forward.” A migrated record stops being an archival concern the moment cutover is verified, because it is now a live record in a validated, supported system, subject to that system’s own backup, access control, and eventual retirement. Confusing migration with archival produces the opposite failure from confusing backup with archival: instead of a stranded, unreadable blob, you get a record nobody owns operationally because everyone assumed someone else had migrated it. See data migration validation for how a migration itself gets verified.

The decommissioning project must explicitly state which of these it is delivering. A decommissioning plan that says “we will keep the final database backup” has confused the two and has almost certainly created a gap. See backup, restore, and disaster recovery validation for the availability side; everything below is about the record side.

Determine Retention Before You Touch Anything

Why retention drives the whole project

You cannot decommission correctly until you know how long each record type must survive, because the retention period decides whether a record gets migrated, archived, or destroyed, and it sets the duration over which the archive must stay readable. Get the period wrong on the short side and you destroy records you were legally required to keep. Get it wrong on the long side and you carry cost and litigation exposure for data you could have lawfully disposed of.

Retention requirements come from several places at once, and the governing rule is that when more than one applies, the longest wins. For US drug and biologics GMP, 21 CFR 211.180 sets minimums: most batch and production records are kept at least one year past the batch expiry, and for products with no expiration date, at least three years after distribution. EU GMP imposes its own minimums, and for some record categories, such as those tied to advanced therapy products, EU expectations reach 30 years. Clinical records under ICH E6(R2)/E6(R3) and trial master file expectations have their own long horizons. Pharmacovigilance records, tax and financial records that intersect with GxP systems, and contractual or litigation obligations can each extend the period further.

21 CFR 211.180(a): records “shall be retained for at least 1 year after the expiration date of the batch or, in the case of certain OTC drug products lacking expiration dating … 3 years after distribution of the batch.”

The practical move is to build a retention schedule by record type, not by system. A single system holds many record types with different clocks. A LIMS holds stability data, release test results, environmental monitoring data, and method validation data, and these may carry different retention periods and different start events. The clock start matters as much as the duration: “10 years” means nothing until you fix whether it counts from record creation, from batch expiry, from product discontinuation, or from end of the study.

How to determine retention, step by step

1. Inventory every record type the system holds. Not tables, record types: batch records, test results, audit trails, user administration logs, configuration, validation evidence, electronic signatures, attachments.
2. For each record type, identify every applicable regulation, standard, and contractual obligation. Involve Quality, Regulatory, and Legal; do not let one function decide alone.
3. For each, capture the retention duration and the clock-start event in plain language.
4. Where multiple rules apply to one record type, take the longest duration and the latest clock start.
5. Add any active legal hold (covered below), which overrides and suspends destruction regardless of the schedule.
6. Record the determination in a controlled document, approved by Quality and Legal, that becomes part of the decommissioning package.

Acceptance criteria

Retention determination is complete when every record type in the system has a documented retention period and clock-start event, every period traces to a named source obligation, the longest-wins rule has been applied where rules overlap, Legal and Quality have approved, and any record type whose retention has already expired and is not under hold is explicitly marked as eligible for disposition.

Worked example: retiring a legacy LIMS

A LIMS supporting QC for a marketed biologic is being replaced. The retention analysis produces this:

The longest clock here is stability data tied to a batch that may not expire for years, plus the post-expiry retention, plus a possible EU extension. The archive must stay readable for that full horizon, which sets the requirement that drives every later decision.

The Migrate-Versus-Archive Decision

For each record type, there are three fates: migrate it into the successor system, archive it in a form independent of any application, or destroy it because its retention has lapsed and no hold applies. This decision is the analytical core of a decommissioning project.

When to migrate

Migrate when the data is still operationally needed in the successor system: trending continues, the data feeds ongoing decisions, or users genuinely need to query it as live data. Migration means the records become part of a validated, supported system again, which is the cleanest long-term outcome but the most expensive and the highest risk during the move. Migration is its own validated activity with its own integrity proof, mapping, and reconciliation. Do not improvise it as a side effect of decommissioning; treat it as a project governed by data migration validation.

When to archive

Archive when the data must be retained for compliance or potential future need, but is not part of ongoing operations. Most decommissioned data falls here. You do not need to keep paying to run an obsolete application just to satisfy a one-in-a-thousand future retrieval, but you absolutely must keep the records retrievable. Archival extracts the records and their context into an application-independent form and stores them under controls that outlive the source system.

When to destroy

Destroy only when retention has fully lapsed for that record type and no legal hold applies, and only with the formal certificate-of-destruction process below. Destruction is the one irreversible step in the entire discipline, so it carries the heaviest controls.

The decision in practice

Mixed outcomes within one system are normal and expected. A common pattern: migrate the last few years of release data into the new system for trending continuity, archive the older release data and all stability and EM data, and destroy nothing yet because nothing has cleared its retention plus hold. Document the per-record-type decision and its rationale; an inspector reviewing decommissioning will ask why each record type went where it went.

Acceptance criteria

The decision is sound when every record type has an assigned fate (migrate, archive, or destroy) with a written rationale, no record type defaults to “keep the old system running indefinitely” by omission, migration follows a validated migration process, archival targets an application-independent format, and destruction is gated on lapsed retention plus absence of hold.

Freeze-and-Archive vs Migrate-Forward: the Practical Trade-off

The per-record-type decision above answers what happens to each record type. A separate, higher-level question sits above it for any decommissioning project with a genuine successor system in scope: does the whole cutover freeze the legacy system read-only on day one and archive everything, or does it migrate the still-relevant slice forward and only then freeze what remains? Both are legitimate strategies, and the wrong choice for a given system tends to show up either as a project that drags on for years with the legacy system still limping along, or as a successor system quietly missing data users assumed had come across.

Most real decommissioning projects are not purely one or the other; the decision table above already shows that a single system commonly produces a mix. This trade-off is about which strategy carries the default for a system, because the default drives budget, timeline, and how much of the legacy system has to stay operational during the transition. Stating the default explicitly, and documenting the exceptions to it, is what keeps a mixed-disposition project auditable instead of ad hoc.

Build an Archive That Stays Readable for the Full Retention Period

This is where decommissioning succeeds or fails. The archive has to be readable by a human, and processable by a machine, for the entire retention period, which may be 10, 15, or 30 years into a future where the source application, its database engine, and its operating system no longer exist and cannot be licensed or run.

Human-readable and machine-readable, both

A defensible archive is dual-format by design.

The human-readable copy lets a person open and understand a record with nothing more exotic than a PDF reader or a web browser, years from now, with no specialist software. For a batch record, that is a rendered document showing the data, the audit trail, the signatures, and the metadata in a form a reviewer or inspector can read directly. PDF/A is the usual target because it is an ISO-standardized archival format designed for long-term preservation and is self-contained. The key property is that reading it depends on nothing from the dead application.

The machine-readable copy preserves the structured data so it can be searched, reconciled, and, if ever needed, re-imported or analyzed. Open, non-proprietary, well-documented formats are the goal: XML or JSON with a documented schema, or delimited text with a defined layout, rather than a proprietary binary database file that only the original engine can parse. A documented schema is part of the deliverable, because structured data with no schema is only marginally better than no data.

Why both? The human copy guarantees a person can always read a record without rebuilding anything. The machine copy guarantees the structured relationships, the searchability, and the ability to reconcile counts and re-analyze survive. Drop either and you have a partial archive. A pile of 40,000 PDFs with no index is unsearchable; a structured dump with no rendering is unreadable by anyone without the schema and tooling.

Format obsolescence is the real adversary

The threat is not a disk failing tomorrow; backup and storage controls handle that. The threat is slow: the format you archived in becomes unreadable over 15 years because the only software that ever read it is extinct. Defenses, in order of preference:

• Archive in open, standardized, long-lived formats from the start (PDF/A for rendering, open structured formats for data). This minimizes future dependence and is the strongest defense.
• Migrate the archive forward when a format approaches obsolescence, under change control, with re-verification that the migrated archive is still complete and faithful. An archive is a managed asset over its whole life, not “set and forget”.
• Avoid emulation as the primary strategy. Keeping an old virtual machine around to run the dead application is fragile, costly, and itself ages out (the VM needs a host, the host needs an OS, licenses lapse). Use emulation only as a temporary bridge while you extract to open formats, never as the long-term answer.

How to build it, step by step

1. Extract the full record set from the source system, not a filtered or summary export. Pull raw structured data and all linked objects (audit trail, signatures, attachments, metadata).
2. Render each retained record into the human-readable archival format (e.g., PDF/A) with its audit trail and metadata embedded or directly linked.
3. Export the structured data into the open machine-readable format with a documented schema.
4. Build an index: a catalog that lets a future user find a specific record without opening the application, by batch number, sample ID, date, product, and so on.
5. Generate integrity proofs: record counts, and checksums or hashes on the archived files, so completeness and non-alteration can be demonstrated later.
6. Reconcile the archive against the source: counts match, a sample of records compares field-for-field, the audit trail is present and complete.
7. Place the archive on storage with its own backup, access controls, and integrity monitoring, independent of the retiring system.
8. Validate the archive and its retrieval process: prove you can find, retrieve, and read an arbitrary record, with its audit trail, from the archive alone.

Acceptance criteria

The archive is defensible when each retained record exists in both a human-readable and a machine-readable form, both forms are independent of the source application, the structured form has a documented schema, an index allows retrieval without the original system, integrity proofs (counts plus checksums) exist and reconcile against the source, and a documented test has retrieved a real record end to end from the archive alone.

Cloud and SaaS System Decommissioning

Everything above applies to a cloud or SaaS system too, but a vendor-hosted system adds a dependency the earlier sections do not have to deal with: you do not control the infrastructure, and in many cases you do not control the export tooling either. The vendor’s cooperation is not a nice-to-have at the end of the relationship; it is a control that has to be established before the relationship starts and verified periodically while it runs, because the moment you actually need it is the worst possible time to discover it does not work the way the contract implied.

Set the exit terms at onboarding, not offboarding

The single biggest cloud-decommissioning mistake is treating data export as an offboarding problem. By the time a contract is ending, whatever negotiating position existed to set export terms is gone, and the vendor has little commercial incentive to invest engineering time on behalf of a departing customer. The export capability, its format, and the vendor’s obligations belong in the contract signed at onboarding, alongside the usual service-level and security terms:

• A defined data export format, ideally an open, documented, non-proprietary format (structured data with a schema, not a proprietary database dump only the vendor’s own software can read).
• A defined export scope that explicitly includes audit trail, metadata, and electronic signature records, not only the primary data tables; a vendor’s default export function is often built for a customer moving to the vendor’s own next product, not for a full independent extraction.
• A committed timeframe for producing an export on request, and a committed post-termination window during which the vendor retains the data and will still produce an export if asked again.
• The right to test the export mechanism periodically during the active contract, not only at termination, so a broken or incomplete export is caught while there is still a working relationship to fix it through.
• Advance notice obligations if the vendor plans a platform change, an acquisition, an end-of-life for the specific product, or a data model change, since any of these can affect export fidelity going forward.

The SaaS data portability and exit readiness checklist is built around exactly this: running the export test before you sign, at intervals during the contract, and again at actual exit, rather than trusting a clause that has never been exercised. See also cloud and SaaS validation for how the vendor relationship shapes the validation approach across the system’s whole life, not only at the end.

What the export actually needs to contain

A cloud export that satisfies decommissioning has to carry the same elements a records-based archive from an on-premises system needs: the data, its audit trail, its metadata, and the meaning of any electronic signatures, in a form independent of the vendor’s application. A vendor export that hands back only the current-state values, with no history of how a record reached that state, is not usable as a decommissioning archive regardless of how complete it looks on the surface. Confirm this by example, not by reading the contract language: request a real export of a record with a multi-step audit trail and check that every step, and its attribution, survived the export.

When the vendor is the one that disappears

Retention periods regularly outlive vendor relationships, and sometimes they outlive the vendor itself. A SaaS provider can be acquired and sunset the product, run out of funding, or exit the regulated-industry market entirely, at any point during a record’s retention period, including years after your contract with them has already ended. Plan for this rather than discovering it after the fact:

• Treat a completed, verified export as the actual archive; do not treat “the vendor still has it and I could ask for it again” as a substitute for archival. Once the export is extracted, verified, and stored under your own control, the vendor’s continued existence stops being a dependency.
• Where contract terms allow, a data escrow arrangement, a periodically refreshed independent export held by a third party, gives a fallback if the vendor becomes unreachable, unresponsive, or insolvent before a scheduled export was pulled.
• If a vendor announces an acquisition, a sunset date, or a bankruptcy filing, treat it as an immediate trigger to pull and verify a fresh export, even if a routine archival extraction was not otherwise due, because the window in which a distressed or acquired vendor can still produce a working export closes fast.
• A vendor’s own retention or backup practices are not a substitute for your archive. A vendor backup exists to protect the vendor’s service, on the vendor’s schedule and format, and is not contractually or technically equivalent to your decommissioning archive even while the vendor is healthy.

Acceptance criteria

Cloud or SaaS decommissioning is adequate when the export format, scope, and timeframe were defined in the contract before or independent of any termination event, a real export has actually been tested and shown to carry the full record including audit trail and metadata, the export has been extracted, verified, and placed under the organization’s own control rather than left dependent on the vendor’s continued cooperation, and a defined trigger exists to pull a fresh export early if the vendor’s own viability or product roadmap changes.

AI/ML System Decommissioning

A trained model is not a conventional application, and retiring one raises a question the sections above do not: what has to survive is not only the outputs the model produced, but the thing that explains why it produced them. A conventional system’s logic is its code, validated once and then largely static for the system’s life. A model’s logic is inseparable from the data it was trained on; the same architecture trained on a different data set is, functionally, a different decision-maker. Decommissioning has to treat the model artifact, its training data lineage, and the outputs it generated as three related but distinct things, each with its own disposition.

The three things that outlive a retired model

The output row is the least controversial: whatever the model told a user or wrote to a batch record is a record like any other, subject to the same retention-by-record-type logic as the rest of this article. The other two rows are where AI/ML decommissioning diverges from a conventional system.

Why the model artifact and training data need their own disposition decision

If a model influenced a GxP decision, and that decision is later questioned, the question is rarely just “what did the system output”; it is “why did the system output that, and would the same inputs produce the same result today.” Answering that requires the specific model version that was live at the time, and, for anything beyond a surface explanation, the training data and validation evidence that version was built on. A conventional system’s audit trail plus its validated, static logic already answers “why” for a conventional record. A model’s audit trail alone does not, because part of the “why” lives in training data the live system never displays to the user at the point of decision.

This does not mean every training data set must be kept forever by default. It means the disposition decision for model artifacts and training data has to be made deliberately, the same way it is for any other record type, rather than defaulting to deleting the training pipeline once a model ships, as an engineering convenience. Where a model retrains continuously or on a rolling window, capture enough of the lineage, what data window trained which deployed version, and when the transition happened, that a past version’s behavior remains explainable even after the live pipeline has moved on to a newer version trained on newer data. The GxP ML model lifecycle covers how this versioning and lineage discipline gets built during the model’s active life; decommissioning is the point where that discipline either pays off or reveals it was never kept up.

A retired model can still be functionally relevant

One more distinction from a conventional system: a decommissioned conventional system generally stops mattering the moment its data is safely archived, because nobody expects the retired code to explain anything on its own; the record and its audit trail are self-sufficient. A retired model can still be functionally relevant even though it is no longer deployed, because someone may reasonably ask it to reproduce or explain a specific past inference. Where that is a realistic future need, the archived bundle has to keep the model artifact, its exact training data lineage, and its validation results linked together as one unit, with enough environment information (library versions, inference parameters) to make re-running the archived model version at least plausible, rather than archiving the weights file alone and assuming that is equivalent to archiving a database of results.

Acceptance criteria

AI/ML model decommissioning is adequate when every production model version’s outputs are retained per their record type, the model artifact for any version that made retained decisions is itself archived with a recoverable version identity, the training data and lineage supporting each archived model version are retained and linked to that version rather than treated as disposable pipeline intermediates, and the retention period applied to the artifact and lineage is at least as long as the retention period of the decisions that version produced.

Preserve the Audit Trail, Metadata, and Signatures

A record without its audit trail and metadata is not the record; it is a screenshot of the answer with the working torn off. Yet audit trail and metadata are the first casualties of a careless extract, because the easy export, the one the application offers as a report, is usually the result values only.

Why this is the hardest part

The audit trail and metadata live in different tables, sometimes different subsystems, from the result data, and the link between them is internal to the application. A naive “export results to CSV” gives you the values and loses the who/what/when/old-value/why that makes them trustworthy. The same applies to electronic signatures: the meaning of a signature (who signed, in what capacity, when, with what intent) is metadata bound to the signed record, and an extract that drops it leaves a result that nobody, on the record, ever approved. The integrity attributes the live system enforced, the ALCOA+ properties in the ALCOA+ principles in detail, must survive into the archive, or the archived record fails the same tests the live one passed.

What must be preserved

That last row matters for laboratory data especially. A chromatogram is a dynamic record: in the live system you can reprocess it, change integration, and see the effect. A flat PDF of the final peak table is a static copy that loses the ability to see what the data could have shown under different integration. Where reprocessing context is part of the integrity story, preserve the raw structured data, not only the rendered output. See static and dynamic records and true copies and, for chromatography traps, chromatography data system integrity.

How to verify preservation

For a representative sample of archived records, prove from the archive alone that you can still answer: who created this value, who changed it and from what to what and why, who approved it and when, what method and instrument produced it, and which batch or sample it belongs to. If any of those requires going back to the dead application, the extract was incomplete and must be redone before the application is gone, because after shutdown there is no second chance.

Acceptance criteria

Preservation is adequate when, for a sampled set of archived records, the full audit trail, all integrity-relevant metadata, the electronic signatures with their meaning, and the inter-record relationships are all present and readable from the archive alone, with no dependence on the retired application.

Periodic Retrievability Testing

An archive is a claim until you test it. Storing files and assuming they will be readable in 2038 is exactly the assumption that fails. Regulators and the integrity guidances expect that archived data remains retrievable and readable throughout the retention period, which means the archive must be exercised, not just held.

Why test periodically rather than once

Three things degrade silently over a long retention period: the storage media, format readability, and the retrieval process plus the knowledge to run it. A one-time validation at archive creation proves the archive worked the day it was made. It says nothing about whether it still works five years later after the storage was migrated, the index tooling upgraded, and the people who built it gone. Periodic testing converts “we believe it is fine” into “we proved it last quarter”.

How to run a retrievability test

1. Define a frequency in the archive’s procedure, risk-based on retention length and criticality (annual is common; longer retention or higher criticality argues for more often).
2. Select records to retrieve, ideally a random sample plus any known-tricky cases (large attachments, complex audit trails, dynamic records).
3. Retrieve each selected record from the archive using the documented retrieval process, with no recourse to the original application.
4. Confirm both formats open and are complete: the human-readable copy renders fully, the machine-readable copy parses against its schema.
5. Confirm the integrity attributes survive: audit trail, metadata, signatures, relationships, all present.
6. Verify integrity proofs still hold: checksums match, counts reconcile against the original archive manifest.
7. Record the test: what was retrieved, by whom, the result, any issues, and remediation.
8. On any failure, raise a deviation, fix the archive (migrate format, repair index, restore from the archive’s own backup) under change control, and re-test. See deviation management.

Worked example

That single failed render is the entire reason for periodic testing. It would have been invisible until the day an inspector asked for that exact record, by which point it would be a finding instead of a routine fix.

Acceptance criteria

Retrievability testing is in place when the frequency is defined and risk-based, each test retrieves a sample using only the archive, both formats and all integrity attributes are confirmed, integrity proofs are re-verified, results are recorded, and failures route to deviation management with re-test on closure.

The Certificate of Destruction

Destruction is the only irreversible act in this whole discipline, so it gets the tightest control. You destroy GxP records only when retention has fully lapsed for that record type and no legal hold is in force, and you prove the destruction with a controlled certificate.

Why a certificate, not just a delete

The certificate is evidence that disposal was deliberate, authorized, time-bound to lawful eligibility, and complete. Its job runs in both directions. It shows you did not destroy records you were required to keep (each line is gated on lapsed retention and no hold), and that records you were entitled to dispose of are genuinely gone, which matters for privacy obligations and for limiting future litigation exposure. “We think it got deleted at some point” is the answer that turns a routine question into a finding.

What goes on the certificate

How to destroy, step by step

1. Identify record types whose retention has fully lapsed per the schedule.
2. Run a hold check against the active legal-hold register; exclude anything under hold.
3. Obtain documented authorization (Quality and Legal at minimum).
4. Execute destruction by the defined secure method appropriate to the medium and to any privacy requirements.
5. Verify completeness and irrecoverability.
6. Issue and sign the certificate of destruction.
7. Retain the certificate itself: the certificate is a GxP record and is kept indefinitely or per policy, because it is the proof that the destruction was lawful.

Acceptance criteria

Destruction is controlled when every destroyed record type had fully lapsed retention, a hold check was performed and documented, Quality and Legal authorized it, a secure method was used and verified, a complete certificate was issued and signed, and the certificate is itself retained as a record.

Common trap

The most common destruction mistake is not over-keeping; it is destroying on a system basis when retention runs on a record basis. Someone retires a system and disposes of “the old data” wholesale, sweeping up record types whose clock had not run, or that were under a hold nobody checked. Destruction must be per record type, gated individually, never a single bulk action on a whole system.

Legal Hold

A legal hold is an instruction to preserve records relevant to actual or anticipated litigation, investigation, audit, or regulatory action. It overrides the normal retention schedule completely: while a hold is in force, the records it covers cannot be destroyed even if routine retention has lapsed. Destroying records under hold, even by routine automated cleanup, is spoliation, and it carries consequences well beyond a GxP finding.

Why it must be wired into decommissioning

Decommissioning is precisely when legal hold is most likely to be violated, because it is the moment you are actively planning to dispose of data. An automated retention-cleanup job, or a wholesale “wipe the old system” step, will happily destroy records under hold unless the hold is checked first. The hold check is therefore a mandatory gate in front of every destruction action, and the legal-hold register must be consulted as part of the decommissioning plan, not assumed to be someone else’s problem.

How to handle holds during decommissioning

1. Before any disposition, query the active legal-hold register (owned by Legal) for every record type in scope.
2. For any record type under hold, suspend all destruction, and ensure the archive itself preserves those records intact and retrievable for the duration of the hold, which may exceed the routine retention.
3. Confirm the archive’s own integrity controls cannot inadvertently age out or overwrite held records.
4. When Legal releases a hold, document the release, then re-evaluate the record type against the routine retention schedule before any disposition resumes.
5. Keep the hold and release documentation as records; the trail of “held, then released, then disposed under normal schedule” is what defends the eventual destruction.

Acceptance criteria

Legal hold is handled correctly when the active hold register is consulted before any disposition, held record types are excluded from destruction and preserved intact, the archive cannot inadvertently destroy held data, hold releases are documented before disposition resumes, and the hold-and-release history is retained.

Roles and Responsibilities

Decommissioning fails when ownership is fuzzy, because it spans business, Quality, IT, Legal, and Validation, and each assumes another function has the long tail covered. Map it explicitly. See data governance framework and GxP roles and responsibilities.

The segregation that matters most: the function that authorizes destruction (Legal/Quality) must be distinct from the function that executes it (IT), and the hold check must sit with Legal, not be self-certified by whoever wants the old system gone. Where small-organization staffing collapses these, document a compensating control such as a mandatory independent second authorization on every certificate of destruction.

The system owner also has one closing duty that is easy to treat as an afterthought: updating the validated system inventory to show the system as retired, with a pointer to where its records now live. An inventory that still lists a decommissioned system as active is a specific, recurring inspection finding on its own, separate from anything wrong with the archive itself. See GxP system inventory and classification.

Worked Example: One System’s Full Lifecycle, Decommission to Eventual Destruction

The sections above cover each piece of decommissioning on its own. Seeing them run in sequence, against real dates, makes the dependencies between steps concrete: nothing here happens in isolation, and several steps are gated on the one before it.

Timeline: a legacy environmental monitoring system

Two things this timeline makes visible that a single-section treatment does not. First, the legal hold in 2029 arrived eight years after the system was decommissioned and three years before any destruction was even due, which is exactly the ordinary case the hold register has to handle, not an edge case. Second, the single format migration in 2033 is the archive behaving as a managed asset over a very long life, not a one-time deliverable that gets filed away and forgotten.

Common 483-Type Mistakes

These are the recurring failure patterns, stated generically:

• Kept the database backup, lost the records. A final backup retained with no archival extract; the application is gone and the backup is unreadable. The single most common decommissioning failure.
• Results archived without the audit trail. The easy export gave values only; the who/what/when/why was never extracted, so the archived record is not reconstructable and the chance to fix it died with the application.
• No periodic retrievability test. Archive validated once at creation, never exercised again; nobody notices a format or index has gone unreadable until an inspector asks for a specific record.
• Destroyed records still under retention or hold. Wholesale “wipe the old system” that swept up record types whose clock had not run or that were under a legal hold nobody checked.
• Proprietary, application-locked archive format. Data archived only in the source application’s native format, readable only by software that no longer exists.
• Migration done as a side effect, unvalidated. Records moved into the successor system with no mapping, no reconciliation, no integrity proof, so completeness and fidelity were never demonstrated. See data migration validation.
• No certificate of destruction. Records disposed of with no controlled evidence of what, when, by whom, under what authority, and that no hold applied.
• Legal hold not wired into the cleanup. An automated retention job or a decommissioning step destroyed records under hold, turning a routine task into spoliation.
• Retention determined per system, not per record type. A single blanket period applied to a system holding record types with very different clocks, leading to either over-retention or premature destruction.
• Dynamic record flattened. A chromatogram or other dynamic record archived only as a static print, losing the reprocessing context that is part of its integrity.
• Cloud export never tested until the day it was needed. An export clause sat in the contract untested for years; at actual exit the export was incomplete, proprietary, or missing the audit trail, with no remaining negotiating position left to fix it.
• Vendor viability treated as a substitute for archival. Data left sitting in an active SaaS account with no independent, verified export, on the assumption the vendor would always be reachable; the vendor was later acquired and the product sunset before an export was ever pulled.
• Model retired, weights deleted, training data never disposition-decided. A model’s outputs were retained as records, but the specific model version and the training data lineage behind a later-challenged decision were gone, so the “why” behind an already-retained output could not be reconstructed.

Interview Questions and How to Answer Them

Expect these in a data integrity, CSV/CSA, or validation interview, and variants from inspectors reviewing a retired system.

“What is the difference between a backup and a decommissioning archive?” A backup protects availability of a running system and has a short horizon; success is the system restarting. A decommissioning archive protects the record itself after the application is gone, for the full retention period; success is retrieving a complete, readable record with its audit trail, with no dependence on the original software. Keeping a final database backup is not archival, because once the application is gone the backup is unreadable.

“How do you decide migrate versus archive versus destroy?” Per record type, not per system. Migrate if the data is still operationally needed in the successor system, as a validated migration. Archive if it must be retained for compliance but is not in daily use, in an application-independent dual format. Destroy only when retention has fully lapsed for that record type and no legal hold applies, under a controlled certificate.

“How do you make sure an archive is still readable in fifteen years?” Archive in open, standardized, long-lived formats (PDF/A for rendering, open structured formats with a documented schema for data) so readability does not depend on the dead application; migrate the archive forward under change control as formats approach obsolescence; and run periodic retrievability tests that retrieve real records from the archive alone and confirm both formats and all integrity attributes still work.

“Why is preserving the audit trail the hard part of decommissioning?” Because the trail and metadata live in different tables from the results and are linked internally by the application. The easy export gives values only and silently drops the who/what/when/old-value/why and the signatures. Once the application is shut down there is no way to recover them, so you must extract and verify the full trail before decommissioning, not after.

“What is a certificate of destruction and what is on it?” Controlled evidence that disposal was deliberate, authorized, and lawful: the record types and identifiers destroyed, the lapsed retention basis, an explicit hold check, Quality and Legal authorization, the secure method used, date and operator, verification of completeness, and signatures. The certificate is itself a retained record.

“What is a legal hold and how does it interact with retention?” An instruction to preserve records relevant to litigation, investigation, or regulatory action. It overrides the retention schedule: held records cannot be destroyed even if routine retention has lapsed. During decommissioning, the active hold register is a mandatory gate before any destruction, and destroying held records is spoliation.

“You are retiring a CDS. Walk me through it.” Determine retention by record type, longest rule wins, clock starts fixed. Decide per record type: migrate, archive, or destroy. For archived data, extract full structured data plus audit trail, metadata, signatures, and the raw dynamic data for chromatograms; render human-readable PDF/A and export open machine-readable data with a schema; index it, generate checksums, reconcile against source. Validate the archive and its retrieval. Run the legal-hold check before destroying anything; destroy only lapsed, unheld record types under a signed certificate. Then schedule periodic retrievability tests for the full retention period.

“How do you decommission a SaaS system when you don’t control the infrastructure?” Set export format, scope, and cooperation terms in the contract at onboarding, not at exit, because the ability to negotiate favorable terms is gone by termination. Test the actual export periodically during the active contract, confirming it carries audit trail and metadata, not only current values. Once a real export is verified, treat it as the archive and stop depending on the vendor; a vendor’s continued existence, or its own backups, are not a substitute for an archive under your own control.

“How is decommissioning an AI/ML model different from decommissioning a conventional system?” A conventional system’s logic is static code, so its outputs plus their audit trail are self-sufficient once archived. A model’s logic is inseparable from its training data, so explaining or reproducing a past decision can require the specific model version, its training data lineage, and its validation results, not only the output. Decommissioning a model means making a deliberate disposition decision for the artifact and its training lineage, not only for the predictions it made.

The Durable Principle

Decommissioning is the test of whether records were ever really yours or only on loan from the application that happened to hold them. The discipline is simple to state and hard to do: the records, with their audit trail and metadata, must outlive the system, stay readable to a human and a machine for the full retention period, never depend on resurrecting dead software, and be destroyed only when lawfully eligible and never while held. If you can retire a system today and, a decade from now, retrieve any of its records complete and readable inside an hour, you have done it right. If retrieval would require rebuilding an obsolete application from a backup, you kept a liability and called it retention. The work to avoid that is done before the system is switched off, because afterward the source of truth is gone and the gap cannot be closed. For the broader picture of where archival sits in a record’s life, see the data lifecycle and metadata; for retiring systems that were never properly validated in the first place, see retroactive validation of legacy systems.