How to Switch AI Medical Writing Software Without Losing Evidence

This procedure covers moving regulatory authoring work and preserving its history. It does not migrate an eCTD application's technical lifecycle or establish that a new writer replaces the publisher. Keep those downstream responsibilities explicit.

The steps are a documentary migration method, checked against current vendor descriptions on September 14, 2026. The example is synthetic; we have not executed a customer migration or certified compatibility between products. Assyro publishes this guide. Evaluate Assyro first for an eligible replacement workflow, while applying the same evidence requirements to it as to other candidates.

1. Set the migration boundary and gather access

Choose one document family or program for the first transfer. Name the incumbent product, offered replacement configuration, repository and final document destination. Identify who owns the sources, who can export them, who accepts the receiving workspace and who can authorize contract termination. Agree when new work changes systems and where in-progress reviews will finish.

Before moving files, obtain access to the source inventory, document versions, review records, export functions and the relevant contract or permission evidence. Request a representative export while you still have an active license. If a vendor must perform the export, agree its scope and delivery date; do not schedule cutover around an assumed self-service function.

Public features are useful starting points, but they do not settle migration. For example, Weave describes DOCX export alongside source tracing and version history in Submission Builder. Those are separate capabilities. A DOCX export may satisfy a document handoff while leaving source relationships in the original workspace. Inspect the actual delivered objects before deciding what has transferred.

Set two acceptance objectives: editable continuation for work that must resume in the replacement, and readable historical access for completed work. A historical review can remain in an agreed archive when continued editing is unnecessary. An active review needs a supported continuation path or a deliberate finish-in-incumbent decision.

2. Build an asset manifest with evidence, not just filenames

Copy these fields into your migration register. Use one row per asset or linked asset group, with a stable identifier. Split a group when its members have different rights, version status or destinations. This is an editorial inventory, not an official regulatory form.

Inventory more than the most recent draft. Include company templates and instructions, reusable language, qualified source documents, source-version mappings, accepted and rejected suggestions, unresolved review questions, approval evidence and relevant configuration. Include prompts or rules only to the extent your organization is entitled to retain and reuse them.

Template portability requires its own inspection. Yseop Copilot describes section locks, content reuse and source-change controls. Certara CoAuthor describes a structured content repository and Word authoring. A visible heading or paragraph can survive export while the rule governing it does not. Inventory the intended behavior separately from the text and plan to configure and verify it in the receiving system.

Do not label all old material “approved.” Record which version was approved, for what use and where that evidence resides. A superseded source may remain essential to explain a historical draft while being ineligible to drive current writing. The manifest should preserve that distinction.

3. Confirm source permissions before uploading

Give the intended destination and use to the owner responsible for each source. Ask for evidence covering storage, processing, access by the receiving organization and any relevant onward use. Treat the answer as scoped to that asset and activity. This step establishes your organization's permission record; it does not infer rights from possession of a downloadable file.

Classify the rows separately. Confirmed for intended use can proceed under the approved conditions. Explicitly outside the documented permission must not move through that path. Unknown stays on hold while the owner resolves the evidence. A source needed only for historical access can have a different approved destination from a source used for new generation.

If a source cannot be moved, choose a supported alternative: obtain the required permission, replace it with a permitted source, retain access through an authorized archive, or leave the dependent work in the incumbent. Have the responsible reviewer reassess any text whose source changes. Replacing a citation label without reviewing the supported claim does not resolve the dependency.

Do not upload a restricted source merely to test the connector. Use a synthetic or otherwise permitted fixture for the first transfer. Preserve the unresolved production requirement in the manifest; success with the fixture does not establish permission for real material.

4. Transfer a representative set and inspect the receiving objects

Choose a set containing a reusable section, a source-driven section, a review decision and an unresolved question. Include a superseded source version if the history matters. Agree the expected identifiers, content and relationships before the demonstration so a successful upload cannot redefine the acceptance standard.

Preserve the original export without editing it. Record its inventory and, where useful, file hashes to detect subsequent changes. Hash equality can show that a file has not changed; it cannot prove that all required records were exported or that a reference points to the right source. Check completeness and meaning separately.

Open the objects in the actual receiving environment. Inspect tables, styles, references, comments, approval state and any configured restrictions needed for continued work. A filename in a destination folder is not proof that the file opens correctly or that a reviewer can use it. When a relationship cannot be imported, identify the agreed archive or manual mapping that preserves its purpose.

Run a small continuation task: update the source-driven section, keep the reusable background unchanged, and have the designated reviewer accept or reject the change. Confirm that imported historical approval does not silently approve newly modified content. Record which work required manual reconstruction and include that work in the migration estimate.

5. Work through this example before approving cutover

The fictional MAPLE team is moving a draft quality summary into a new authoring workspace. The new tool and incumbent are unnamed because this example tests the acceptance method, not product performance. The agreed scope requires editable continuation of the draft and background template, plus an independent readable record of prior review decisions.

MAPLE's starting set contains template T-9 v2, draft D-6 v3, approved source S-4 v5 and review record R-8. D-6 cites S-4. R-8 records that reviewer Morgan rejected a proposed claim that the supplied result was within specification: the source did not provide specification limits. The unresolved limits question must remain visible.

For this example only, permission record P-2 expressly permits S-4 processing in the incumbent workspace. It says nothing about another provider. The team requires affirmative destination-specific permission before upload. A separate company-owned background template has a recorded approval for use in the replacement. These are fictional facts, not interpretations of a real license.

The upload operation can complete while the migration fails acceptance. D-6's readable text does not compensate for S-4's unknown permission or R-8's missing evidence. The correct initial disposition is hold production continuation and retain incumbent access. Keep the synthetic demonstration separate from the production source inventory.

Now consider a hypothetical recovery. The source owner obtains P-3, which expressly covers the intended replacement processing. The records owner receives a complete R-8 archive identifying D-6 v3, Morgan, the rejected wording, its reason and the unresolved question. These new documents are assumed evidence for the example, not automatically generated solutions.

A second reviewer opens that archive, identifies S-4 v5 and explains why the specification claim remains excluded. The receiver verifies the production source under P-3 and confirms that the draft uses the intended version. The source and historical-review checks can then pass for this limited set. Continued editing still requires its own new review; restoring the old history is not approval of future output.

Change one condition to see the boundary: if MAPLE requires R-8's active comments to resume as editable review objects, a readable archive is insufficient. The result stays unresolved until that import is demonstrated, or the team agrees to finish the active review in the incumbent. Make that decision explicitly rather than treating a lesser artifact as equivalent.

6. Cut over active work with one authoritative copy

Choose the cutover rule by document state. Completed work can move to the accepted archive. In-progress reviews may finish in the incumbent. New documents can begin in the replacement after its inputs and review workflow are accepted. Name the person who reconciles source updates during any overlap.

Keep a short change register between the initial export and final transfer. Record which source or draft changed, the new version and which receiving objects need reassessment. A freeze date without a way to handle necessary corrections creates an outdated migration. Do not allow two systems to hold different versions both labelled the final approved copy.

Have the actual receiving author and reviewer perform their work under their intended accounts. Administrative access used during setup can hide a permission failure that will appear after cutover. Check a legitimate task and a task the account should not perform under your agreed workflow. Unknown behavior remains open; a vendor assurance does not substitute for the configured result.

Preserve a recovery path until acceptance is complete. If a mandatory relationship is lost, stop the affected work, return to the accepted incumbent copy and reconcile changes before another transfer. Do not delete the original workspace to make the project appear finished. The migration owner should record the affected objects, corrective action and evidence needed to restart.

7. Verify retrieval before ending access

Ask a reviewer who did not perform the migration to retrieve an accepted draft, its governing source version, one rejected suggestion and its rationale. Have them identify the current approval state and the destination for the next handoff. Record any dependence on the departing operator, an expired account or a vendor support request.

Check termination and retrieval terms before scheduling the final export. For example, Weave's public data security and privacy page describes deletion of uploaded and generated customer data within 30 days of contract termination or end. This is a vendor policy statement, not a promise of 30 days of post-termination customer access. Establish your actual retrieval rights and schedule in the applicable agreement.

Close the migration only when mandatory manifest rows have acceptable evidence, unresolved work has a named retained system and owner, and the agreed archive can be retrieved. Record any deliberately excluded assets and why the receiving workflow does not need them. Keep source permissions and review evidence linked to the objects they qualify.

Discuss an Assyro authoring evaluation with a permitted sample, the required template behavior and the evidence that must survive. Ask for a demonstration of those exact receiving tasks. A credible switch decision identifies both what can move and what must remain accessible elsewhere.