Navata
← All Library

Change & Migration

What Evidence Is Needed Before Decommissioning a Legacy GxP System?

AI-assisted research and drafting · Practitioner reviewed by Rohith Karanam Sreedhar · 8 September 2026

ⓘ Library content is researched and drafted with AI assistance and reviewed by a Navata practitioner before publication. For original analysis and long-form practitioner perspectives, visit Navata Insights →

A successful data load does not prove a legacy system is ready to retire. Migration verifies movement into a target. Decommissioning must establish that the organisation can operate, retrieve and defend the retained record without returning to the source.

The retirement decision should be evidence-led because shutting down infrastructure can remove context that appeared unimportant while the live application was available: code translations, historical metadata, audit history, report logic, user identities and relationships between records.

Define which retirement decision is being made

Teams often use “decommissioned” for several different states:

  • new transactions are prohibited but read access remains;
  • the application is available only to administrators;
  • records have been exported to a validated archive;
  • application services and infrastructure are shut down;
  • storage is retained without the original application;
  • records are destroyed under an approved retention policy.

These states have different evidence needs and reversibility. Record the proposed state, effective date, remaining technical components, permitted access and later destruction path. Do not allow a project milestone called “system retired” to conceal that the database and specialist support must remain indefinitely because nobody validated retrieval elsewhere.

Establish the record population and applicable retention

Identify the regulated record classes held by the system and the rule or policy governing each retention period. There is no single universal GxP retention duration. Requirements depend on the record, product, activity and jurisdiction.

For each class, document:

  • authoritative source population and count;
  • date range and lifecycle states;
  • required content, metadata and audit information;
  • relationships needed to interpret the record;
  • retention trigger and calculated destruction date;
  • legal hold or investigation constraints;
  • target repository or archive;
  • accountable record owner.

Counts help detect missing records but do not prove completeness. Ten thousand files can arrive while the status history, reason for change or link to the approved product is lost. Reconciliation should cover the attributes necessary to find, interpret and defend the record.

Prove migration completeness and exception disposition

The migration package should connect the approved scope to what actually moved. That normally includes source extracts, transformation rules, load results, reconciliation, rejected records, manual corrections and final approval.

Every exception needs a stable source identity and a disposition. Typical outcomes include corrected and reloaded, retained only in the legacy archive, excluded because it is non-regulated or duplicate, or accepted with a documented limitation. Aggregate success percentages should not erase a small number of records with high regulatory significance.

MHRA's data-integrity guidance says migration procedures should have a rationale and be designed and validated to maintain integrity through the data lifecycle. Annex 11 similarly expects checks where data are transferred to another format or system. Neither turns a record count into a complete decommissioning test; the organisation must determine which content and context are necessary.

Validate retrieval without the legacy application

Run retrieval tests from the state that will exist after shutdown, not from a temporary environment that still has live source access. Select records across:

  • record types and lifecycle states;
  • early and late date ranges;
  • amended, superseded and cancelled records;
  • records with attachments and relationships;
  • restricted access groups;
  • migrated exceptions;
  • records likely to be requested together during an investigation or inspection.

The user should be able to locate the record using expected search attributes, open it in a readable form, interpret its status and version, retrieve necessary metadata and audit history, and understand linked evidence. Measure accuracy and retrieval time where operational or inspection commitments depend on it.

Annex 11 expects archived data to remain accessible, readable and protected, with the ability to retrieve it tested. A backup image is not automatically an archive. Backup demonstrates recoverability of a technical copy; archival must preserve accessible and intelligible records over the required period.

Check historical intelligibility

A record may be readable and still be impossible to interpret. Preserve the meaning of:

  • retired user IDs and organisational roles;
  • historical status and reason codes;
  • obsolete controlled vocabularies;
  • units, date formats and calculated values;
  • relationship types and parent-child structures;
  • electronic signatures and their associated meaning;
  • report definitions used for regulated decisions;
  • system and configuration versions where needed to explain behaviour.

Where codes are transformed, retain an approved mapping and evidence that the target representation did not change meaning. Where the original user directory will disappear, retain enough identity context to attribute actions appropriately.

OECD's data-integrity advisory document provides lifecycle and retention principles within GLP scope. It should not be represented as universal GMP authority, but its emphasis on complete, consistent and reconstructable data reinforces the same practical concern: retention without context can preserve bytes while losing the record.

Remove residual operational dependencies

Inventory more than interfaces listed in the project plan. Look for scheduled jobs, extracts, reports, bookmarks, integration accounts, data-warehouse feeds, robotic processes, spreadsheets and support procedures that still point to the legacy application.

Ask each process owner to demonstrate the replacement path for:

  • completing open work;
  • answering a historical query;
  • producing a recurring report;
  • investigating a discrepancy;
  • supporting an inspection request;
  • correcting an archival or migration error;
  • placing or releasing a legal hold.

Monitor attempted connections and user access during a controlled read-only period where practical. A quiet interface inventory does not prove no dependency exists; observed use can expose unofficial reports and workarounds.

Close open records and responsibilities

Open records should not disappear into the migration boundary. For each open workflow, deviation, action, training assignment or approval, decide whether it will complete in the source, continue in the target, or be closed and recreated with an explicit link.

Assign continuing owners for the archive, access approvals, retrieval testing, security monitoring, retention changes, destruction and incident response. Decommissioning the application does not decommission the obligations attached to its records.

Supplier and licensing arrangements must support the retained design. Where reconstruction or reading depends on the former vendor or a continuing licence, treat that as an explicit archival dependency: define the service and access required, control it contractually, test retrieval through it and show that it is sustainable for the full retention period. The weakness is not dependency itself, but an unrecognised or uncontrolled dependency that the retirement decision assumes has disappeared.

Build the retirement approval from evidence

A defensible approval package should state:

  • exact retirement state and components affected;
  • approved record and retention inventory;
  • reconciliation and exception results;
  • retrieval and intelligibility test results;
  • unresolved limitations and risk acceptance;
  • residual-dependency assessment;
  • open-record dispositions;
  • backup, archive and restoration responsibilities;
  • access and cybersecurity treatment;
  • future destruction authority and evidence;
  • named operational owners.

The approver should be able to answer two questions independently: can the organisation defend the retained record after the legacy environment disappears, and can it operate every current process without quietly returning to that environment?

Sources