Every quality manager I talk to who is still running paper wants the same thing: get off the binders without a quarter where nothing ships. That fear is reasonable. A quality system is not a side process you can pause while you swap tools — it is the thing that lets you release product at all. If document control, training records, or CAPA tracking go dark for even a week, you either stop shipping or you ship without control, and neither is acceptable in a regulated environment.
The good news is that stopping production is not actually required, and it never has been. What's required is sequencing. A paper-to-digital migration fails when it's treated as a single cutover event — flip the switch on Monday, hope for the best. It succeeds when it's treated as a series of small, reversible steps where paper and digital run in parallel just long enough to prove the digital system works, and not a day longer.
This is a practical framework for that sequencing: what to migrate first, how to validate as you go, how to handle open records that span the cutover, and how to know when you're actually done — not just when the software is installed.
Why "Big Bang" Cutovers Fail
The instinct to do it all at once is understandable — one project, one training session, one go-live date. In practice, a full cutover forces you to validate every module, migrate every historical record, and retrain every employee against a single deadline. Any one piece can slip:
- A supplier record that doesn't map cleanly.
- A CAPA that's mid-investigation.
- A training matrix that doesn't match reality.
When one does, the whole go-live is at risk, and the pressure to hit the date starts overriding the pressure to get it right.
I've come to think the real risk isn't the software. It's the moment where a document exists in two places at once and nobody is sure which one is the controlled copy. That ambiguity — not the tool itself — is what auditors flag and what actually causes deviations. Under ISO 9001:2015 clause 8.5.1, you're required to maintain control of production under controlled conditions throughout a transition, not just after it's finished. A migration plan has to account for that middle stretch, not just the before and after.
The Phased Migration Framework
Rather than one cutover, break the migration into modules and sequence them by risk and dependency. Each phase runs in parallel with paper until it's proven, then paper is retired for that module only. The week ranges below are per module, not a single company-wide calendar — a lower-risk module can enter Phase 5 and retire its paper record while a higher-risk module is still mid-Phase 4, because each module's timeline is driven by its own parallel-run evidence, not the others'.
Phase 1: Document Control (Weeks 1–4)
Start here because everything else depends on it. Training records reference procedures. CAPAs reference procedures. Audits reference procedures. If document control isn't solid, nothing built on top of it will be either.
- Migrate your master document list first, not the documents themselves. Confirm every controlled document has one owner, one current revision, and one location of record before you touch content.
- Digitize documents in order of review cycle, not alphabetically — anything due for periodic review in the next 90 days gets migrated and re-approved in the new system as part of that review, so you're not doing double work.
- Keep the paper master list "frozen" (no new approvals in the old system) the day the digital document control module goes live for a given document set. A document either lives in paper or in digital — never split mid-revision.
Phase 2: Training Records (Weeks 3–8, overlapping Phase 1)
Training can run alongside document migration because it depends only on which documents are already digitized. As each SOP moves to the new system, migrate the associated training matrix and historical completion records with it.
- Import historical records as read-only history; don't try to "re-certify" people for training they already completed under a valid procedure.
- Assign new training only through the digital system from day one of a document's migration — this avoids the worst failure mode, which is a training assignment that exists in both systems and gets marked complete in one but not the other.
Phase 3: Nonconformance, CAPA, and Change Control (Weeks 6–12)
This is the highest-risk phase because these records are often open and multi-step at the moment you migrate. Never migrate a record mid-investigation. Instead:
- Close out or hold all open CAPAs and change controls in paper. Anything closed before the cutover date stays paper-of-record permanently — you do not need to re-key closed history into the new system to get value from it, only to reference it.
- Anything still open at cutover finishes in paper, start to finish, even if that means running the paper CAPA log for another 60 days after everything else has moved. Trying to migrate an open investigation mid-stream is how root cause analysis gets lost in translation.
- All new nonconformances, from the go-live date forward, open only in the digital system.
Phase 4: Supplier Quality and Audit Records (Weeks 10–14)
By this point the system has proven itself on internal records. Supplier files and audit history are lower risk because they're referenced less frequently day-to-day, which makes this a reasonable phase to migrate historical scans and supplier scorecards without holding up production.
Phase 5: Retire Paper and Lock the Cutover (Week 12+)
Once every module has run in parallel long enough to catch its own errors — typically one full quality cycle, meaning at least one internal audit and one management review conducted using digital data only — retire the paper system for that module. Don't retire paper company-wide on a single date. Retire it module by module, on the date each module has actually proven itself.
Parallel Run vs. Phased Cutover vs. Big Bang
| Approach | Production risk | Validation burden | Typical timeline | Best fit |
|---|---|---|---|---|
| Big bang (single cutover) | Highest — one failure point stops everything | All modules validated simultaneously | 2–4 weeks | Very small operations with minimal open records |
| Full parallel run (paper + digital, everything, indefinitely) | Low, but doubles workload | Moderate, but drags out | 6+ months, often never fully closes | Organizations with heavy regulatory scrutiny already scheduled |
| Phased module-by-module (recommended) | Low — each module isolated | Incremental, module-sized | 12–14 weeks | Most regulated manufacturers under enterprise scale |
The phased approach costs a few extra weeks compared to a big bang, but it buys something a big bang can't: at any point in the process, you can stop, fix a module, and continue without touching the modules already live. That optionality is worth more than the time saved by rushing.
Validating the Digital System While Production Continues
For manufacturers operating under GxP requirements, moving quality records into new software isn't just a change management exercise — it's a computer system validation exercise. ISO 13485:2016 clause 4.1.6 requires validation of software used in the quality management system, and if you're under FDA jurisdiction, 21 CFR Part 11 governs the electronic records and signatures that replace your paper approvals.
You don't need to validate the whole system before migrating anything. Validate module by module, in the same order you migrate:
- Installation qualification confirms the software is deployed and configured as intended for the module going live.
- Operational qualification confirms the module performs its intended function — a document routes to the right approvers, a training assignment triggers on the right trigger, a CAPA escalates on the right timeline.
- Performance qualification runs the module against real records during the parallel-run period, which is exactly when you'd be running it anyway. This is the efficient part of a phased migration: your parallel run and your PQ evidence are the same activity.
FDA's guidance document "Part 11, Electronic Records; Electronic Signatures — Scope and Application," issued August 2003, narrowed enforcement discretion around Part 11 but did not remove the underlying requirement that electronic signatures be as trustworthy as handwritten ones. If your digital QMS is going to carry approval signatures for batch release or CAPA closure, that trustworthiness has to be demonstrated, not assumed. GAMP 5 (published by ISPE) is widely used as an industry framework for scaling validation rigor to the risk of the system. A document control module and a batch record module do not need identical validation depth, and GAMP 5's risk-based categories are a standard way to make that distinction defensibly.
Handling the Records That Span the Cutover
The hardest part of any migration isn't the steady-state records — it's the ones open on the day you flip a module live. A few rules that hold up in practice:
- A record started in one system finishes in that system. Never migrate a record mid-lifecycle.
- The cutover date for a module is the date new records open in digital, not the date old records finish in paper.
- Keep a single migration log — one document, not scattered notes — that records which module went live on which date, who approved the cutover, and what the parallel-run evidence was. This becomes the audit trail for the migration itself, and auditors will ask for it.
What Auditors Actually Look For
An auditor reviewing a mid-migration quality system isn't looking for the migration to be finished. They're looking for control during the transition. In practice that means:
- Can you show, for any given record, whether it lives in paper or digital, and why?
- Is there a single point where someone could argue two conflicting versions of the same document are both "current"?
- Did records that were open during cutover get closed in the system where they started, or did they get abandoned in one system and half-restarted in another?
A clean answer to those three questions matters more to an auditor than whether you're 40% or 90% migrated. Auditors have seen migrations before. What worries them is ambiguity, not incompleteness.
A Realistic Timeline
For a single-site manufacturer with a few hundred controlled documents and a handful of open CAPAs at any given time, twelve to fourteen weeks from kickoff to full digital cutover is a realistic target using the phased approach above. Organizations with multiple sites or heavier regulatory obligations — combination products, sterile manufacturing, multi-country distribution — should expect the CAPA and supplier phases to run longer, since those records tend to be both higher volume and higher scrutiny.
What should not stretch is Phase 1. Document control is the foundation every other phase depends on, and letting it drag creates a compounding delay across everything downstream. If document control is taking longer than four to six weeks, the more common cause is that the "master list" wasn't actually accurate before the migration started — the migration just surfaced that.
Getting Started
The organizations that migrate successfully treat this as a sequencing problem, not a software problem. Pick the module with the lowest risk and the highest dependency — document control — and prove the parallel run works before touching anything with an open investigation attached to it. Production never has to stop. It just has to be sequenced so that no record is ever ambiguous about where it lives.
For more on what a full cutover plan and vendor data migration should look like in detail, see switching QMS vendors: data migration, validation, and cutover planning, and for the broader case on what paperless actually requires under FDA expectations, see paperless QMS and FDA expectations.
Frequently Asked Questions
How long does a paper-to-digital QMS migration take? For a single-site manufacturer, a phased migration typically runs 12 to 14 weeks from kickoff to full cutover, module by module. Organizations with multiple sites or heavier regulatory scrutiny should expect the CAPA and supplier phases to extend beyond that.
Do I need to revalidate my QMS software before go-live? Yes, if you operate under ISO 13485 or FDA GxP requirements. ISO 13485:2016 clause 4.1.6 requires validation of software used in the quality management system, and validation should be scaled to each module's risk rather than treated as a single all-at-once event, per the risk-based approach described in GAMP 5.
What records should be migrated first? Document control, because training records, CAPAs, and audit records all reference controlled documents. Migrating document control first means every later phase has a stable foundation instead of referencing procedures that exist in two places at once.
Can paper and digital systems run in parallel? Yes, and they should — module by module, not system-wide. Running a module in parallel during its validation performance qualification period lets you generate real validation evidence while keeping paper as the system of record until the digital module is proven.
What happens to CAPAs or change controls that are open when we migrate? Finish them in the system where they started. A record opened in paper closes in paper, even if that means running a shrinking paper CAPA log for a few weeks after every other module has moved to digital. Migrating an open investigation mid-stream risks losing root cause context.
Last updated: 2026-08-28
Jared Clark
Founder, Nova QMS
Jared Clark is the founder of Nova QMS, building AI-powered quality management systems that make compliance accessible for organizations of all sizes.