eQMS Legacy Data Migration: DHF, DMR, DHR Done Right

Where eQMS Rollouts Actually Fail

The vendor demo always looks great. Configurable workflows, integrated audit trail, electronic signatures, beautiful dashboards. The selection committee signs off, the procurement team negotiates the contract, and rollout begins.

Twelve months later, the eQMS holds new records perfectly. But the design history files for the existing five products still live in shared drives. The complaint records from 2019-2023 sit in spreadsheets. The CAPAs from before the rollout are PDFs in a folder. The KGMP audit happens, and auditors find the legacy records — which they will, because they ask for "the design history file for product X" and product X was developed before the eQMS — and the integrated audit story falls apart.

eQMS rollouts fail at legacy data migration more often than at any other phase. Not because migration is impossible — it is well-understood work — but because organizations under-invest in it relative to the visible work of configuring workflows and training users.

This guide covers a working migration approach, with Korean KGMP audit considerations woven in.

What Actually Needs to Migrate

Not everything needs to live in the eQMS. A practical scoping framework distinguishes three tiers:

Tier 1 — must migrate. Active product records that will be audited. For a typical mid-size manufacturer with 5-15 marketed products:

• Design History Files (DHF) for all currently marketed products
• Device Master Records (DMR) for all currently produced products
• Device History Records (DHR) — typically retained per regulatory retention requirements (10+ years from product EOL)
• Active CAPAs and recently closed CAPAs (last 5 years)
• Active complaints and recently closed complaints (last 5 years)
• Active vigilance reports and recently closed reports
• Current Quality Manual and procedures
• Active supplier qualification records
• Current training records for current personnel
• Active risk management files

Tier 2 — selectively migrate. Legacy records with audit relevance:

• DHF/DMR for discontinued products still within retention window
• Older CAPAs and complaints (older than 5 years but still within retention)
• Historical management review minutes
• Closed audit reports (internal and external)

Tier 3 — leave in legacy storage. Records that meet retention requirements but have low audit-pull probability:

• Pre-launch design documents for current products (e.g., research-phase prototypes)
• Discontinued product full DHRs older than 7 years
• Historical training records for departed personnel

A documented tiering decision, signed by the quality lead, is itself an audit artifact. Auditors who learn that some records are in legacy storage want to see the reasoning.

The Five-Phase Migration Plan

A workable migration runs in five phases. Total duration: 12-24 months for a mid-size manufacturer; longer if multiple sites are involved.

Phase 1 — Inventory and Triage (Months 1-3)

Physically walk the existing record storage. Catalog every folder, every shared drive location, every records system. Tier each finding. Produce:

• Records inventory (one row per source folder or system)
• Triage decisions (Tier 1, 2, or 3 for each)
• Volume estimate (page count, document count, file size)
• Migration priority sequence

The most common surprise in this phase: records exist in places nobody documented. Engineering shared drives, individual laptops, paper boxes from acquisitions. Plan for 30-50% more volume than initial scope.

Phase 2 — Metadata Mapping (Months 3-6)

eQMS systems organize records by structured metadata (record type, product, lot, date, owner, status, etc.). Legacy storage usually organizes by folder structure and filename convention. The mapping work translates one to the other.

For each record type, define:

• Source location pattern (e.g., \\fileserver\design\product-X\verification\*)
• eQMS destination object type (e.g., DHF Verification Record)
• Required metadata fields (auto-extracted, manually mapped, or set to default)
• Version handling (how revisions are captured)
• Linkage rules (e.g., verification record links to design input it satisfies)

Metadata mapping is the most under-budgeted phase. It is also where the migration's audit defensibility is determined. If metadata is wrong, downstream queries return wrong results.

Phase 3 — Cleansing and Normalization (Months 5-10)

Legacy records often have inconsistencies that block clean import:

• Same product referenced by different names (development codename vs commercial name)
• Same person referenced by different IDs (employee ID vs email vs name)
• Same supplier referenced by different vendor names
• Date format inconsistencies (US, EU, ISO, free-form)
• File format variation (PDF, scanned PDF, Word, Excel, paper-only)

Cleansing rules document the normalization decisions. Cleansing scripts execute them. Manual review handles the residual cases that automation can't resolve.

Phase 4 — Migration Execution (Months 6-18)

The actual data transfer. Best practices:

• Migrate in batches by product or by record type, not all at once. Smaller batches surface issues earlier.
• Two-pass migration: first pass for primary records, second pass for cross-references and dependencies that require primary records to exist first.
• Maintain a migration log — every batch, with source counts, destination counts, errors, and reconciliation. This log is itself an audit artifact.
• Computer System Validation (CSV) coverage. The migration procedure itself is a validated process. See the dedicated Computer Software Validation guide for the CSV framework.

Phase 5 — Reconciliation and Retirement (Months 12-24)

After migration, validate that every Tier 1 record landed correctly:

• Sample-based comparison (typically 10% of records by type)
• Targeted high-value checks (every design input traces to verification, every CAPA has a closure record, etc.)
• User acceptance testing — actual quality and regulatory staff using the migrated records for real work

Then formally retire the legacy storage (or move to read-only archive). Document the retirement decision, scope, and access controls. KGMP and FDA inspectors increasingly ask about legacy storage retirement; an undocumented archive can become a finding.

Korean KGMP Audit Specifics

Korean KGMP audits have particular emphases relevant to migration.

Bilingual record requirement. Korean KGMP scope expects records relevant to Korean operations to be retrievable in Korean. Pure-English migration leaves a translation gap. The mitigation is bilingual key documents (Quality Manual, top-level procedures, summary records) with English-only deeper documents.

Traceability emphasis. Korean auditors specifically probe traceability from finished device serials back to design and manufacturing records. A clean genealogy query in the eQMS demonstrates traceability; a manual reconstruction does not. Migration should preserve genealogy links explicitly.

Korean import records. For foreign-manufactured devices, the KLH-side import record (lot-level traceability from Korean import through Korean disposition) is its own data stream. The migration should include this stream — typically by integrating the KLH's import records system with the manufacturer's eQMS.

Korean complaint and adverse event records. Korean-language complaints and adverse event reports must remain in the eQMS in their original Korean form, with English translations as supporting documents. The original Korean is the record of receipt.

CSV Considerations for Migration

The migration itself is a computer system process and falls under Computer System Validation. Practical CSV scope:

• Migration procedure is validated (typically GAMP 5 Category 4 or 5)
• Migration scripts require validation testing (typically reduced testing for one-time use)
• Reconciliation queries are validated (they need to produce reliable results)
• Migrated records are not "validated" in the CSV sense — they are sourced from existing controlled records, with cleansing/normalization documented per record-type rule

For FDA 21 CFR Part 11 environments, the migration produces electronic records under Part 11 scope from the moment of migration. The chain of custody from legacy storage through migration to eQMS must be intact and auditable.

Six Practical Recommendations

1. Budget 20-30% of total eQMS rollout cost for migration. Vendor estimates routinely under-budget this.
2. Migrate Tier 1 first, in priority sequence. Get to "all active product records are in the eQMS" before retiring legacy storage.
3. Validate the migration procedure under CSV, not just the eQMS configuration. The migration is the highest-risk activity.
4. Maintain a migration log as a permanent audit artifact. Inspectors ask about this directly.
5. For Korean operations, integrate KLH-side import records into the migration scope. Treating this as a separate stream creates audit gaps.
6. Do not retire legacy storage until reconciliation is complete and signed. Premature retirement creates recovery emergencies.

Where Leanabl Plugs In

The eQMS service includes migration planning, execution, and CSV coverage for medical device organizations. For Korean operations specifically — where the KLH integration and bilingual record requirements add complexity — the work integrates with Korea QMS Foundation and post-rollout Korea Audit Readiness for KGMP inspection preparation.