How-To Jul 12, 2026 · 16:24 7 min read By Daniel Herrmann

GxP Data Archiving During Decommissioning: Preserve Records Until Final Retrieval

Plan GxP system retirement, migration, archiving, retrieval testing and controlled shutdown without breaking the regulated data lifecycle.

GxP data archiving during decommissioning is complete only when relevant data and metadata have been fully migrated or placed in a controlled archive, remain readable and retrievable throughout the retention period, and are protected against unauthorised change. Turning off the server is the final technical step, not the start of the project.

Why the data lifecycle does not end when the replacement goes live

System replacements are often planned as migration projects: transfer data, train users and release the new application. That view is incomplete for a GxP-relevant legacy system. Historical data may remain relevant for batch disposition, stability, complaints, inspections or product decisions for years.

EMA describes the data lifecycle from generation and processing through use, storage and retrieval to controlled disposal at the end of the retention period. For computerised systems, business process owners and IT should review the lifecycle together. EU GMP Annex 11 also expects archived data to remain accessible, readable and integral, and retrievability to be assured and tested when relevant changes are made to the system.

That is the purpose of GxP system decommissioning: the organisation does not preserve a legacy application for its own sake. It preserves the ability to use required records completely and with context.

Step 1: Define scope and accountability

Scope starts with intended use and business processes, not with a server list. An ERP, LIMS, MES or eQMS may contain several GxP-relevant functions, interfaces and data objects. The team should establish:

which regulated processes and products the system supported;
which data, metadata, audit trails, signatures and reports are records;
which interfaces, file stores, archives and satellite systems form part of the data flow;
which retention periods and ongoing business uses apply;
who approves completeness, access design, test evidence and final shutdown.

A decommissioning owner coordinates the work, but accountability remains distributed. The process owner assesses usability and completeness, QA assesses GxP compliance, IT owns architecture and operation, records management owns retention, and information security owns protective controls.

Step 2: Inventory data and metadata

A common gap is an inventory limited to tables or document files. A complete record may also require its version, user attribution, timestamps, audit trail, electronic signature, status, master-data relationships or the calculation logic used at the time.

For each relevant data object, the inventory should capture at least:

Field	Guiding question
Business purpose	Which decision or evidence relies on the record?
Source	In which system, module or store is it generated?
Context/metadata	What is needed to preserve meaning and reconstruction?
Retention	How long and under which requirement?
Target state	Migration, validated archive, read-only system or controlled disposal?
Retrieval	Who must search, view and export it, and in which format?
Protection	How are access, alteration, loss and deletion controlled?

This inventory connects the regulatory requirement with technical implementation. A successful row count does not prove that a record will remain understandable later.

Step 3: Select the target architecture by risk

There is no universally correct retirement architecture. Three patterns are common.

Migration into the replacement system. This fits data that will remain operational and whose semantics, relationships and functions can be represented reliably. It may add unnecessary complexity when historical records are rarely read in the new application.

Transfer to a validated archive. This suits records that must remain searchable, viewable and exportable but should no longer be processed. The archive needs a defined data model, access controls, protection against change, backup and recovery, and a tested retrieval function.

Read-only operation of the legacy system. This can be a temporary solution, but it retains infrastructure, knowledge, licence and security dependencies. Over time, hardware, operating systems, authentication or viewers may become unsupportable.

The decision should consider data criticality, remaining retention period, retrieval frequency, dependencies, cyber risk, operating cost and availability of suitable viewing and export functions.

Step 4: Specify and test migration or archiving

Assurance should be proportionate to risk. For structured data, a file count alone is rarely sufficient. Relevant tests may include:

completeness by object, period, site or product;
value equivalence and treatment of rounding, character sets and time zones;
preservation of relationships between record, metadata, audit trail and signature;
correct representation of status, version and history;
search, display and export for typical inspection requests;
permissions and protection against unauthorised change;
backup, restore and recovery of the target archive;
documented treatment of exceptions and objects that cannot be migrated.

For large data sets, automated completeness controls combined with risk-based business sampling may be appropriate. Selection and acceptance criteria should be defined before execution. GxP system validation of the target and validation of the migration process are connected but not identical workstreams.

Step 5: Qualify retrieval as a business process

An archive is not usable merely because IT can open a file. A future user must be able to locate the correct record within an appropriate time, display it completely and provide it for its intended purpose.

Retrieval tests should therefore reflect real scenarios, for example:

locate a batch or material history using defined search attributes;
display the record that was effective at the relevant time, including status and approval;
provide audit trail or change information linked to the record;
create a readable, controlled export for an inspection;
retrieve the record again after restoring the archive.

The tester should represent the future user role. Testing performed only by the migration team can hide usability and knowledge dependencies.

Step 6: Approve shutdown criteria and residual controls

Before shutdown, the project needs a documented decision. Useful exit criteria include:

approved data and metadata inventory;
completed migration or archiving with deviations resolved or accepted;
passed retrieval, access and restore tests;
assigned owner and operating process for the target archive;
defined retention, legal hold and controlled disposal;
updated system inventories, procedures, contracts and continuity records;
disabled interfaces, technical accounts and user access;
approved residual actions with owner and due date.

Only then should the application, infrastructure and interfaces be retired in a controlled manner. Media or remaining copies should not be deleted informally; their treatment follows retention, security and disposal controls.

Step 7: Maintain the archived state

Accountability does not end with the closure report. Platform migrations, viewer updates, identity changes, key rotation or organisational changes can make an archive unusable.

The operating process should therefore assess, at a risk-based frequency:

accessibility and readability of selected records;
effectiveness of access controls;
backup and restore capability;
technical obsolescence and support status;
remaining retention periods and planned disposal;
changes that trigger a new retrieval test.

Decommissioning thereby becomes a controlled end state in the system lifecycle, not a one-off infrastructure task.

Common mistakes

“We will migrate everything.” This moves data without establishing whether context, relationships and future retrieval are preserved.

“The PDF is the record.” A PDF may be readable while losing audit trail, signature context, version or structured relationships.

“Read-only means risk-free.” An immutable legacy system can still fail, become unpatchable or depend on a small number of knowledgeable users.

“The server can go after go-live.” Without approved completeness, retrieval and restore evidence, future data availability has not been adequately demonstrated.

Frequently asked questions

Must all historical data be migrated into the new system?

No. Migration, archiving or temporary read-only operation may be appropriate depending on intended use, retention and risk. Relevant records must remain complete, protected, readable and retrievable.

Is a database backup a sufficient GxP archive?

Usually not as the sole evidence of usability. A backup supports recovery. An archive must also preserve controlled access, meaning, readability, search and retrieval throughout the retention period.

When may the legacy system be switched off?

When approved exit criteria are met: data and metadata have been migrated or archived under control, deviations assessed, retrieval and restore tested, accountability assigned, and interfaces and access terminated in a controlled manner.

Primary sources

Author

Daniel Herrmann Consulting supports Pharma and Biotech organisations in retiring validated systems, from data inventory and migration to archiving, retrieval testing and controlled legacy shutdown.

Are you replacing SAP, LIMS, MES or an eQMS?

For SAP validation and other replacements, we structure scope, data decisions, evidence and shutdown criteria so the new system can go live without losing the historical GxP record.

Discuss system decommissioning