Migrating existing documentation

Guide · For Admins · 6 min read

Principle: build on what you have

Your existing documentation is the source of truth. Migration does not mean regenerating it; it means bringing it into the workspace so agents can read from it and maintain it going forward.

Step 1 — Inventory

List where documentation currently lives: a docs site, a wiki, shared drives, PDFs. Note which sets are public and which are internal, and who owns each.

Step 2 — Import

Import each set into the workspace. Structure and headings are preserved; formatting is normalised to your matter conventions on the first maintenance pass, not on import, so nothing changes until a reviewer approves it.

Step 3 — Baseline review

Agents produce a baseline report: duplicated topics, pages that contradict each other, pages with no owner, and references to old versions or dates. Each finding becomes a proposed change in the review queue. Approve them in any order.

Step 4 — Assign owners and review periods

Apply default owners and review periods from the workspace, then adjust individual matters where needed. Renewal dates found in documents are extracted and attached to the matter for reminders.

Step 5 — Publish

Once the baseline is approved, publish. From this point the continuous loop takes over: releases, reader questions and scheduled reviews keep the set current.

Typical timeline

A single-product documentation set of a few hundred pages usually reaches baseline within two weeks, most of it review time on your side. Larger programmes are migrated one document set at a time.