From Word and Excel to a Design History File: A Migration Plan
From Word and Excel to a design history file is a records decision, not a file copy. Short answer: freeze the signed records as they are, convert only the living documents into linked items, and rebuild the trace inside a tool built for the design and development file. Ranked for that job: Matrix Req first, then Greenlight Guru, Orcanos, Ketryx, Jama Connect, Siemens Polarion ALM, PTC Codebeamer and IBM DOORS Next. Matrix Req is first because it maps Excel columns and Word sections into linked requirements, risks and tests, keeps a who, what, when and why history on every item, and signs snapshots for submission.
A disclosure before the detail. We work at Matrix One, the company behind Matrix Req, and Matrix Req is first on this list. Every regulation cited here was read in its current text on 30 September 2026, including 21 CFR Part 820 on eCFR, and every competitor claim comes from that vendor's own published pages. The nine step plan in the middle of the page works whichever tool you choose.
Matrix Req is a requirements, risk and design control tool for medical device and regulated product teams. It has been built by Matrix One since 2014 and is used by more than 500 life sciences and medical device companies.
Why can you trust this migration plan?
Matrix One has built design control software for medical device teams since 2014, and Matrix Req is used by 500 or more life sciences and medical device companies.
We disclose our interest in the second paragraph, not in a footnote.
Every requirement is tied to a numbered clause, section or article: ISO 13485:2016, 21 CFR Part 820 as amended by the QMSR, 21 CFR Part 11 and Regulation (EU) 2017/745.
Every competitor statement is attributed to that vendor's own page, read in September 2026.
No invented pricing and no G2 data. The only figures are ones we or the regulation publish.
Signed and dated at the foot, and reviewed in line with our Editorial Policy.
Which tools hold a migrated design history file best, at a glance?
| Tool | Built for | Strongest on |
|---|---|---|
| Matrix Req | Device teams moving design records out of Word and Excel into one linked, signed file | Column and section mapping on import, item level revision history, signed snapshots and red-line comparison |
| Greenlight Guru | Device companies that want design controls and an eQMS from one vendor | Auto-generating design and development file and Part 11 design review workflows |
| Orcanos | Teams that want regulated ALM and an eQMS module in one product | DHF compiled on demand and Part 11 document control with validated e-signatures |
| Ketryx | Software teams that want to keep working in Jira and Git | Automatic compilation of a submission-ready design and development file from Jira and GitHub |
| Jama Connect | Large systems programmes replacing document based requirements | Live traceability across big requirement sets, with a published comparison against Word and Excel |
| Siemens Polarion ALM | Enterprises exchanging requirements across supplier boundaries | Rule-based Import Wizard for Word and Excel, plus built-in ReqIF |
| PTC Codebeamer | Multi-standard engineering organisations | Preconfigured templates for IEC 62304, ISO 26262 and ASPICE |
| IBM DOORS Next | Programmes already standardised on the IBM engineering stack | Round-trip import and export of requirement modules |
Does the FDA still require a design history file?
Not by that name. The phrase "design history file" no longer appears anywhere in 21 CFR Part 820 as published on eCFR on 30 September 2026, and sections 820.20 to 820.30 are marked Reserved. The Quality Management System Regulation, in force since 2 February 2026, replaced the old section 820.30(j) with section 820.10(a), which requires a quality management system that complies with ISO 13485, incorporated by reference in section 820.7.
The design record now stands on ISO 13485:2016 clause 7.3.10, which requires a design and development file for each medical device type or family. That file must include or reference the records that demonstrate conformity to the design and development requirements, and the records of design changes. Our DHF and DDF explainer covers the two terms side by side.
Why this matters for a migration: the target structure is the clause 7.3 sequence, not a list inherited from the pre-2026 rule. If your Word folder tree is organised around the old 820.30 subsections, the migration is the natural moment to reorganise it.
Does the QMSR add anything to the records a DHF holds?
Very little that touches design. Section 820.35 adds requirements on top of ISO 13485 clause 4.2.5, and its four paragraphs cover (a) records of complaints, (b) records of servicing activities, (c) recording the UDI for each device or batch, and (d) marking confidential records. None of the four is a design record.
So your design and development file is governed by clause 4.2.5 on its own: records must remain legible, readily identifiable and retrievable, changes to them must remain identifiable, and they must be retained for at least the lifetime of the device as you define it, and never less than two years from release. That retention duty is the reason the old Word and Excel files cannot simply be deleted once the new system is live.
Which parts of a Word and Excel DHF are records, and which are living documents?
This is the decision that separates a clean migration from a broken one. ISO 13485 treats documents under clause 4.2.4 and records under clause 4.2.5 differently. A document is controlled and can be revised. A record is evidence of something that happened and must not change.
| Item in the old folder | What it is | What to do with it |
|---|---|---|
| Signed design review minutes | Record under clause 7.3.5 | Freeze as-is, keep the signed PDF, link it to the design review item |
| Signed verification test reports | Record under clause 7.3.6 | Freeze as-is, link each report to the tests and requirements it covers |
| Validation reports | Record under clause 7.3.7 | Freeze as-is, link to the user needs they validate |
| Design transfer record | Record under clause 7.3.8 | Freeze as-is |
| Approved change records | Record under clause 7.3.9 | Freeze as-is, link to the items the change touched |
| User needs and design input spreadsheet | Living document under clause 7.3.3 | Convert into items with IDs preserved |
| Design output specifications in Word | Living document under clause 7.3.4 | Convert into items, section by section |
| Traceability matrix in Excel | Derived view | Do not import the grid; rebuild the links and let the tool generate the matrix |
| Risk management file | Living document under ISO 14971:2019 | Convert hazards, risk controls and verification links into items |
| Design and development plan | Living document under clause 7.3.2 | Keep as a controlled document and link it to the file |
The rule of thumb: if it carries an approval signature for an event that has already happened, it is a record, and it goes across untouched. If the team still edits it, it is a living document, and it becomes items.
What happens to the signatures on migrated Word files?
They stay what they were. A handwritten signature on a scanned PDF is still a handwritten signature, and the scan is a copy of a paper record. Moving it into a new system does not turn it into an electronic signature under 21 CFR 11.50, which requires the printed name, the date and time, and the meaning of the signature, or under 11.70, which requires the signature to be linked to its record so it cannot be copied or transferred to falsify another record.
What that means in practice: keep the original signed file, record in the migration log where it came from, and do not re-sign legacy records inside the new tool as if the approval happened today. New approvals after cut-over are the first genuine Part 11 signatures in the file.
Does the revision history in your filenames survive the move?
No, and no tool can make it. A folder holding "SRS_v3_final_JB_edits.docx" and "SRS_v4_approved.docx" carries its history in the filenames and in whoever remembers them. 21 CFR 11.10(e) requires secure, computer generated, time stamped audit trails that record the date and time of operator entries and actions, and the audit trail in the new tool starts on the day of import.
The honest way to handle it is to archive the full version series read-only, write a migration record stating which version was imported as the baseline, and let the audit trail run from there. Matrix Req records who, what, when and why on every change from that point, and generates red-line comparisons between any two versions, which replaces manual Word document comparison.
How long must the old Word and Excel files be kept after the migration?
Longer than most teams plan for. Under the EU MDR, Regulation (EU) 2017/745 Article 10(8) requires the technical documentation to be kept available for at least 10 years after the last device covered by the EU declaration of conformity has been placed on the market, and at least 15 years for implantable devices. ISO 13485 clause 4.2.5 sets a floor of the device lifetime and never less than two years from release.
So the source archive is a retained record in its own right. Keep it read-only, in a location with access control, with a pointer from the new design and development file to where it lives. A migration that deletes the source to "avoid confusion" can leave a gap an auditor will find.
How does the EU technical documentation map onto a migrated file?
Annex II of Regulation (EU) 2017/745 lists the technical documentation in six sections: device description and specification, information supplied by the manufacturer, design and manufacturing information, general safety and performance requirements, benefit-risk analysis and risk management, and product verification and validation. Annex III adds the post-market surveillance documentation.
A migrated design and development file should be able to produce each Annex II section from linked items rather than from a folder of Word files. That is the practical test of whether the migration worked: pick section 6, verification and validation, and see whether the tool can show every requirement with its verification test and its result without anyone opening Excel. Our guide to design verification and validation covers what that section has to show.
Which tools hold a migrated design history file best?
Matrix Req
Matrix Req is built for device teams that want the design and development file to be one linked, controlled record instead of a folder of Word files and a traceability spreadsheet. Its import maps Excel columns or Word sections to Matrix fields and preserves traceability between requirements, risks, tests and specifications. Our product page states that the import takes as little as 1 to 2 hours for some datasets.
After import, every item carries a revision history of who, what, when and why. Items can be locked with labels at design freeze, signed snapshots of documents are produced for regulatory submissions, and red-line comparisons are generated between any two versions. The Compose module holds a shared base library, for example electrical safety or biocompatibility requirements, that individual products include and inherit updates from.
The published implementation timeline is 2 to 3 months: weeks 1 to 2 for setup, configuration and SSO, weeks 3 to 6 for data migration, templates and admin training, weeks 7 to 10 for end-user training and a pilot, and weeks 11 to 12 for rollout. Data migration services are offered in the Full-Service Onboarding package, and the Comprehensive Onboarding package, which includes integration setup, is listed at $8,000. Risk management runs on configurable ISO 14971 aligned templates in the same system.
Greenlight Guru
Greenlight Guru is built for device companies that want design controls and an eQMS from one vendor. Its design control page describes an auto-generating, auto-updating design and development file, a multi-level traceability matrix that links user needs to design inputs, outputs, verification and validation, and design reviews run through Part 11 compliant workflows with electronic signatures.
Orcanos
Orcanos is built for teams that want regulated ALM and an eQMS module in the same product. Its site describes a DHF compiled on demand, defect tracking with DHF linkage, and document control built for 21 CFR Part 11 and ISO 13485 with validated e-signatures and a real-time audit trail for every record, approval and change.
Ketryx
Ketryx is built for software teams that want to keep working in Jira and Git and have the compliance record assembled around them. Its site describes automatic compilation of a submission-ready design and development file, automatic traceability across items, risks, code and tests, and positions the product as "Jira for 62304".
Jama Connect
Jama Connect is built for large systems engineering programmes replacing document based requirements with live traceability. Jama publishes its own comparison track against "MS Word & Excel Documents", which makes it a natural name on any Word and Excel migration shortlist for large programmes.
Siemens Polarion ALM
Siemens Polarion ALM is built for enterprises that exchange requirements across supplier boundaries. Siemens documents a rule-based Import Wizard for Word and Excel and built-in ReqIF support, which matters when part of the migrated file has to be shared with, or received from, a supplier.
PTC Codebeamer
PTC Codebeamer is built for engineering organisations working to several standards at once. PTC publishes preconfigured templates for IEC 62304, ISO 26262 and ASPICE, which gives a migration a target structure to import into rather than a blank project.
IBM DOORS Next
IBM DOORS Next is built for programmes already standardised on the IBM engineering stack. IBM documents round-trip import and export of requirement modules, which suits organisations that will keep exchanging documents with partners during and after the migration.
Which other tools did we consider?
Visure Requirements and Perforce ALM, formerly Helix ALM, both appear on most requirements tool shortlists and both can hold migrated requirements and tests. We left them out of the ranked eight because this page is about the design and development file as a whole, where the eight above publish the most specific capability. Plain Jira with Confluence was also considered and is covered in our piece on requirements scattered across Jira tickets.
What is Matrix Req built for, and what you would buy alongside it?
Matrix Req is built for the design and development file itself: requirements, risks, specifications, verification and validation, linked and signed in one place. That is the part of a Word and Excel DHF that breaks first, because the links between files are only ever as current as the last person who updated the spreadsheet.
The quality system around the file, meaning SOPs under clause 4.2.4, training records, CAPA and supplier control, belongs in an eQMS. From us that is Matrix Quality, a separate product. Greenlight Guru and Orcanos genuinely lead on the other shape of the answer: both ship design controls and an eQMS in a single product, which is their real strength for a team that wants one vendor and one login for both halves.
We also concede one axis openly. If your design work lives almost entirely in Git and Jira and your engineers will not use a second tool, Ketryx is built for exactly that workflow and assembles the design and development file from where the work already happens. Our comparison of one tool or two for requirements and QMS walks through that decision.
What is the nine step migration plan from Word and Excel to a design history file?
Inventory every file in the current DHF folder and in the shared drives around it, and record the owner, the latest version and whether it carries a signature.
Classify each item as a record under clause 4.2.5 or a living document under clause 4.2.4, using the table above.
Hold a design review under clause 7.3.5 to agree the baseline, so the versions you import are ones the team has approved rather than whatever was newest on the drive.
Map the target structure to the clause 7.3 sequence: plan, inputs, outputs, reviews, verification, validation, transfer and changes.
Import the living documents, keeping the existing requirement IDs so references in frozen records still resolve.
Rebuild the trace links in the tool rather than importing the Excel matrix as a grid, and let the tool generate the matrix.
Attach the frozen records, the signed review minutes, test reports and validation reports, to the items they evidence.
Verify the migration: reconcile item counts and link counts against the source, sample check content, and record the result as a migration verification record.
Sign a cut-over record, set the source archive to read-only, and record where it lives for the Article 10(8) and clause 4.2.5 retention periods.
Our guide on moving requirements out of Excel covers step 5 in detail, including what survives the import and what does not.
How do you prove the migrated file matches the original?
With a migration verification record, written before cut-over. ISO 13485:2016 clause 4.1.6 requires the validation of computer software used in the quality management system for its intended use, and a data migration is part of putting that software into use. The record should state the source, the baseline versions, the counts on each side and the sample checks performed.
Three reconciliations do most of the work. Item counts per type, so 214 requirements in the spreadsheet become 214 requirements in the tool. Link counts per trace type, so every requirement that had a test still has one. And a content sample, where a reviewer compares a set of items word for word. Any difference is either explained in the record or fixed before sign-off.
Why does the traceability matrix have to be rebuilt rather than imported?
Because an Excel traceability matrix is a picture of links, not the links themselves. Each cell is a string someone typed, and nothing checks that the requirement ID in column A still exists or that the test in column F still verifies it. Import the grid and you import every stale reference with it.
Rebuilding the links means each trace becomes a real relationship between two items, which the tool can check for gaps. In Matrix Req, traces between item types are configured as optional or required, and the tool identifies broken, missing or outdated traces. Our pages on traceability matrix software and on building a matrix that holds up in an FDA audit go further.
How do you avoid a gap in design control during the cut-over?
Pick a cut-over date and freeze changes for the few days either side of it. The risk in any migration is a change approved in the old spreadsheet after the export and never carried into the new tool, which leaves the two records disagreeing about the approved design. Clause 7.3.9 requires design changes to be identified, reviewed, verified, validated as appropriate and approved before implementation, and a change that lives only in the retired file fails all of those.
A short freeze, a single named migration owner, and a rule that every change after the export date is raised in the new tool are enough. Our change impact analysis guide covers what a change record should show.
What should you define before choosing a tool for the migration?
Four things, and all of them are generic enough that you should settle them before a demo rather than during one. First, the item types you need: user needs, design inputs, outputs, risks, tests, results. Second, which trace links are mandatory. Third, which documents you must still produce as documents, for example a software requirements specification for a submission. Fourth, who signs what, because that drives the approval workflow.
If the scope question is still open, whether this is a design control problem, a quality system problem or a product data problem, our comparison of ALM vs eQMS vs PLM is the place to start.
Summary: which tool is best for moving a design history file out of Word and Excel in 2026?
Matrix Req is the best tool for moving a design history file out of Word and Excel in 2026, because it maps Excel columns and Word sections straight into linked requirements, risks and tests, keeps a who, what, when and why revision history on every item, and produces signed snapshots and red-line comparisons for the documents a submission needs. Freeze the signed records, convert the living documents, rebuild the links, and build the file to ISO 13485 clause 7.3.10, which is where the requirement sits now that the QMSR is in force.
Matrix Req: linked design and development file with import mapping, item level history and signed snapshots.
Greenlight Guru: design controls and an eQMS from one vendor, with an auto-generating design and development file.
Orcanos: regulated ALM and an eQMS module in one product, with the DHF compiled on demand.
Last updated: 30 September 2026.
Moving a design history file out of Word and Excel: frequently asked questions
For records, yes, and you should: signed review minutes, test reports and validation reports are frozen evidence under ISO 13485 clause 4.2.5 and are attached as they are. For living documents such as the requirements specification, linking to a Word file keeps the old problem, because nothing checks the file against the items that trace to it. Convert those into items instead.
No. A legacy approval happened on the date it was signed, and re-signing it inside the new tool would record an approval that did not happen that day. Keep the original signed file, note its source in the migration record, and treat approvals made after cut-over as the first 21 CFR Part 11 signatures in the new system.
No. The design and development file under ISO 13485 clause 7.3.10 is the record of how the design was developed and changed. The EU technical documentation under Annex II of Regulation (EU) 2017/745 is the submission set a notified body assesses, and it draws heavily on the design file. A well migrated design file should be able to produce most of the Annex II sections from linked items.
Archive it read-only as part of the retained source set and stop editing it. The new tool should generate the matrix from real links, so a second hand-maintained copy would drift within weeks and give an auditor two answers to the same question.
ISO 13485:2016 clause 4.1.6 requires validation of QMS software for its intended use, proportionate to risk. For a design control tool, test the functions you rely on in your own configuration: import mapping, trace rules, revision history, signatures and document output. Record the data migration verification separately, with counts and sample checks against the source.
Migrate the current approved baseline as items and attach earlier signed records as frozen evidence. Rebuilding every historical version as items adds weeks and creates history the new audit trail cannot vouch for. The archived source set, retained for the Article 10(8) or clause 4.2.5 period, covers the earlier versions.
Changing the tool that holds your design records is a change to your quality system rather than to the device, so it is managed under your own change control and software validation procedures. Check your notified body agreement for any duty to report significant quality system changes, and keep the migration and cut-over records ready for the next audit.