How to migrate a legacy QMS to ArvoDocs using Claude and MCP
Migrate from MasterControl, Veeva, Qualio, Greenlight Guru, Google Drive, SharePoint, or paper — using Claude to read, classify, and load every document and quality record into ArvoDocs in hours instead of weeks.
The single biggest reason teams stay on a QMS they hate is the migration. Even when the new platform is cheaper, faster, and better-designed, the prospect of hand-keying 80 SOPs, re-creating 30 CAPAs, and re-onboarding 25 suppliers feels worse than living with the status quo for another year. So they stay.
Claude changes that math. Connected to ArvoDocs via the Model Context Protocol, an AI assistant can do the data-loading portion of a migration in hours — read every PDF, classify it, map it to a document template, create matching records in your new tenant, populate the compliance fields, and hand off a queue of drafts for a quality manager to review and approve. The regulatory step (the human re-approval) stays where 21 CFR Part 11 requires it to be. Everything else compresses by an order of magnitude.
This post walks the migration playbook — what to migrate, the phase-by-phase prompts, the Part 11 hygiene, and the timing you can plan around.
What you can migrate from
Anything Claude can read becomes a candidate source. The common ones we see:
- • Shared drive (Google Drive, SharePoint, OneDrive, Dropbox) — PDFs and Word docs of SOPs, work instructions, forms. Often the de-facto QMS for early-stage medical device teams.
- • Spreadsheet QMS — Excel or Google Sheets with document registers, CAPA logs, complaint trackers. Common at companies under 20 people.
- • Commercial QMS exports — PDF or XML/JSON exports from MasterControl, Veeva Vault Quality, ETQ Reliance, Qualio, Greenlight Guru, Intelex. Most platforms have an "export everything" function in their admin settings; the output is messy but Claude reads it fine.
- • Paper QMS — physical binders of SOPs and quality records. Scan to PDF first (any office multifunction printer with OCR); Claude reads the OCR'd text directly. This is more common than people admit at small medical device, dental, and food-safety teams.
- • Mixed legacy — half in Drive, half in a spreadsheet, a few stragglers on someone's laptop. Claude handles the heterogeneity better than any consultant: dump it all into the conversation, let it inventory the duplicates and structure, then load.
The MCP server doesn't ingest files directly. The pattern is: you upload your legacy artifacts to a Claude conversation (Claude Desktop, claude.ai web, or Claude Code — all support file attachment), Claude reads them, and then Claude uses ArvoDocs' MCP write tools to create the matching records.
The five-phase migration playbook
Phase 1 — Inventory the source
Before anything moves, Claude needs to understand what's there. Upload your source files (or a CSV index of them) and let it build a map.
"I've attached a folder export from our legacy QMS. Walk through every document. Build a table with: filename, inferred document type (SOP, work instruction, form, policy, manual, record), title, version (if findable), owner (if findable), and a one-line description of what the document covers. Flag duplicates and any document that looks unclear or low-quality."
The output is your migration plan. Review it, fix any classification errors Claude got wrong, decide which documents to migrate, which to skip, and which to merge. This step alone — done with a human + Claude — produces a better inventory than most consultants deliver.
Phase 2 — Build (or verify) ArvoDocs templates
Documents in ArvoDocs are template-driven: every SOP shares a section structure (Purpose, Scope, Definitions, Responsibilities, Procedure, References) inherited from a template. Before migrating documents, make sure your tenant has templates that match the structure of your legacy docs.
"List the document templates in my ArvoDocs tenant. For each one, give me the section structure. Then compare those structures against the sample SOP I just uploaded and tell me whether the existing templates would carry the content faithfully, or whether we need a custom template first."
If you deployed an ISO 13485 or ISO 9001 compliance pack, you already have templates for SOPs, manuals, work instructions, policies, plans, and forms. For exotic document types specific to your industry, you'd create a template once and reuse it for every matching legacy doc.
Phase 3 — Migrate documents
This is the phase that consumes the most human time in a traditional migration and is the cleanest win for AI. Once the inventory and templates are settled, Claude walks the list and creates a draft in ArvoDocs for each document.
"Here are 25 SOPs from our legacy QMS. For each one, create a draft document in ArvoDocs using the SOP template (use list_document_templates to find its UUID). For each draft: set the title to match the original; populate every section with the content from the source PDF, preserving the original headings and structure; set change_description = 'Initial migration from
The assistant runs list_document_templates, create_document, update_document_section for each section, then update_document_compliance_fields — the exact sequence the regulated workflow requires. You end up with N drafts ready for review.
"For the legacy completed forms attached, scan the structure, decide whether each instance should become an ArvoDocs document or be treated as a historical record attached to its parent SOP. For records you classify as 'attach as historical,' generate a CSV mapping the source filename to the parent SOP code. For records you classify as 'migrate as document,' create the drafts directly."
Phase 4 — Migrate quality events (CAPAs, NCRs, complaints)
For open and in-progress events, you want them in the new system so the work continues. For closed events, migrate a representative sample for trending and audit prep.
"Here is our legacy CAPA log (CSV) and the closed-CAPA reports (PDFs) for the open CAPAs and a 20% sample of last year's closed CAPAs. For each one, use list_event_templates to find the CAPA template, then create_event with the original title. Use start_event to activate the first stage. For each field on the active stage, populate from the source PDF using update_event_field_value. For closed CAPAs, populate the historical stages where you can read them; flag any stage you cannot reliably reconstruct."
Migrated events land as drafts (status='active' once started). A quality manager walks them, fixes any reconstruction issues, and submits each stage for human re-approval through the ArvoDocs UI — same workflow as if the events had been native from day one. The original closed-CAPA PDF stays attached as supporting documentation.
Phase 5 — Migrate suppliers and supplier records
Last phase, smallest one. Suppliers are mostly metadata.
"Here is our supplier list (CSV) and the last qualification packet for each Critical supplier (PDFs). For every supplier in the CSV, run create_supplier with name, supplier_type, risk_level, contact info, scope, and products_services from the source. Then update_supplier on each Critical one to fill in next_review_due_at based on the last qualification date plus the re-evaluation frequency. Output the list of new supplier UUIDs at the end."
Suppliers land in draft status; submit for approval through the UI when the data looks good.
The human pass — what Claude doesn't do
Three things stay with the human, and ArvoDocs enforces all of them at the system level.
- • Approval signatures. Every migrated document, every CAPA stage, every supplier qualification approval — they all require a human in the ArvoDocs UI with password re-authentication to move from draft → effective. The MCP server deliberately does not expose those state transitions. This is the 21 CFR Part 11 line, and it stays drawn.
- • Content correctness. Claude reads PDFs accurately but not perfectly. A quality manager has to verify each migrated document's content matches the source, especially for procedures with numerical limits or specific equipment references. The way most teams do this: a side-by-side review pass where the legacy doc is open in one window, the ArvoDocs draft in the other.
- • The migration record itself. Treat the migration as a change-controlled activity. Open a change record in ArvoDocs (or in your legacy system before turning it off), document the scope, the methodology, what got migrated and what stayed as archive, any deviations Claude flagged. Close it with an effectiveness check 30 days post-cutover.
The Part 11 / ISO 13485 paperwork
For teams under FDA or notified-body oversight, the migration itself needs documentation. The accepted pattern is straightforward:
- • Pre-migration: a QMS Migration Plan SOP describing the source system, the target system (ArvoDocs), the scope, the mapping methodology (template ↔ doc type), the validation approach (how you'll verify migrated content matches source), and the re-approval workflow. The ISO 13485 compliance pack ships with a template for this.
- • During migration: a controlled change record tracking what was migrated, by whom (or which MCP-connected user), and when. Every MCP call lands in the ArvoDocs audit trail automatically; you don't need a separate log.
- • Post-migration: effectiveness verification 30 days after cutover — sample a percentage of migrated documents, confirm they're being used correctly, confirm training acknowledgments were captured, close the change record.
This is the same paperwork you'd produce for any QMS transition. The AI doesn't replace it; it just shrinks the data-loading phase from weeks to hours.
How long does it actually take?
A representative migration profile for a small medical-device team:
- • Source scope: 80 documents (SOPs, work instructions, forms), 25 open quality events, 18 suppliers, 5 product families with associated records.
- • Inventory (Phase 1): half a day of human time + Claude. Output is a clean migration spreadsheet.
- • Templates (Phase 2): 1–2 hours if compliance packs cover most of it; longer if you have unusual document types.
- • Document load (Phase 3): 1 day of Claude-driven loading for 80 documents.
- • Event + supplier load (Phases 4–5): half a day combined.
- • Human review + approval (the regulatory step): 3–5 days of quality-manager time, depending on rigor.
Total: ~1 calendar week, with one quality manager spending most of it on the review pass. Compare to the traditional 4–8 week consultant-led migration, and the savings come from the data-entry phase that Claude eliminates entirely.
What about really big migrations?
If you're moving 500+ documents and thousands of quality records out of an enterprise QMS, the same playbook applies but in batches. Claude has context-window limits; for very large source corpora you'd run the inventory phase first, then process documents in batches of 50–100 per conversation, with the migration log accumulating across sessions. The MCP server doesn't care how the data arrives — it's the same create_document + update_document_section calls whether they're triggered in one session or fifty.
For migrations at that scale, the human review pass becomes the dominant cost — at 500 documents and ~10 minutes per review, you're looking at 80+ hours of quality-manager time regardless of how fast the loading happens. AI doesn't change that math; it just removes the data-entry pain on top of it.
The migration scenarios we see most often
"We're outgrowing Google Drive." The most common entry point. The team has 40–80 documents in Drive, no audit trail, no e-signatures, an audit coming up. Claude inventories the Drive folder structure, migrates documents into ArvoDocs SOP/WI templates, deploys an ISO 13485 compliance pack for the documents that don't exist yet, and the team walks into the audit with a real QMS.
"We're moving off MasterControl/Veeva because the contract is up." Larger teams that overpaid for years and want out. The legacy system has an "export everything" function — usually a folder of PDFs plus a metadata CSV. Claude reads the metadata index, migrates documents and open quality events, leaves closed records as archived attachments. The new ArvoDocs tenant is live before the legacy contract expires.
"We're scanning a paper QMS." Dental practices and food-safety operations especially. Run the binders through any office multifunction printer with OCR; upload the resulting PDFs to Claude; Claude classifies and loads. Paper-to-ArvoDocs takes about a day per binder.
"We bought a company and inherited their QMS." Two QMS, one regulated entity. Claude does the de-duplication pass (which company's "Cleanroom Cleaning SOP" wins?), maps conflicting numbering schemes to ArvoDocs' templated structure, and produces a unified document set with a clear audit trail showing which source each document came from.
Migrate your QMS with AI, not a consultant.
Free ArvoDocs Starter plan, ISO 13485 compliance pack in one click, AI integration on every tier — connect Claude and start migrating today.
Start free →Frequently asked questions
Can Claude really migrate my QMS automatically?
Yes, for the data-loading part of the migration. Claude reads source files (PDFs, Word docs, Excel exports, even OCR'd scans of paper SOPs) in the conversation, then uses the ArvoDocs MCP server's write tools to create matching documents, quality events, and suppliers in your new tenant. What Claude doesn't replace is the regulatory step: a human still has to review and approve each migrated record in the ArvoDocs UI with a re-authenticated signature, per 21 CFR Part 11. So the migration goes from 4–8 weeks of manual data entry to a day of Claude doing the loading + a quality manager's review pass.
What source formats can Claude actually migrate from?
PDFs, Word docs (.docx), Excel/CSV (the metadata index, even if the file bodies are separate), Google Docs/Drive exports, SharePoint exports, MasterControl PDF exports, Veeva exports, and OCR'd images of paper documents. Claude reads them as attachments in the conversation, parses out the structure (title, version, owner, sections, content), and uses the MCP write tools to create matching ArvoDocs records. You don't need a specific export format — if Claude can read it, it can migrate it.
How do we handle the audit-trail for migrated records under 21 CFR Part 11?
ArvoDocs ships with a standard 'legacy migration plan' pattern: each migrated document is created as a fresh draft with the compliance fields populated automatically (change_description = 'Initial migration from <previous_system>'; reason_for_change = 'QMS platform transition'; impact_assessment = 'No process change; document content carried forward'). A quality manager reviews each migrated document in the ArvoDocs UI and re-approves it with a signed e-signature. From that approval onward, the document is under controlled-document lifecycle exactly as if it had been authored natively. The migration itself is logged in the tamper-evident audit trail, including which MCP-connected user ran each tool call.
Will a notified body or FDA inspector accept records migrated this way?
Yes, with the right documentation. The accepted pattern: produce a 'QMS Migration Plan' SOP that describes the source system, scope of migration, mapping methodology, validation approach, and re-approval workflow. Treat the migration itself as a change-controlled activity — open a change record, execute the migration, document any deviations or unmappable records, complete an effectiveness check. The migrated documents themselves carry their own approval chain in ArvoDocs; the legacy chain-of-custody lives in the migration record. This is the same approach customers use when moving between commercial QMS platforms; AI just makes the data-loading part faster.
What about historical CAPAs, NCRs, and complaints — do we have to migrate every closed record?
Usually no, and you shouldn't try. Standard practice is to migrate open and in-progress records as drafts (so the work continues in the new system) plus a representative sample of closed records for trending and audit prep. Truly closed records stay accessible in the legacy system or as archived attachments. The migration plan documents what was migrated and what was preserved as-archive. For paper QMS, scan and attach as supporting documents rather than trying to reconstruct field-level data.
How long does this take for a typical small medical device team?
Most small-team migrations (50–200 documents, 10–50 quality events, 10–30 suppliers) take 1–2 days of Claude-driven loading plus 3–5 days of human review and approval. Compared to the traditional 4–8 week consultant-led migration, the savings come from the data-entry phase — humans no longer hand-key documents into the new system, and the structural mapping work that consultants charge for happens in one pass with the LLM.