Three years of architectural decisions live in a wiki, in chat threads and in two shared documents. The team agrees to move decision records into the repository beside the code without a 300-page backfill. Give the sequence, and name the point of no return.

The sequence

1. Start writing new records in the repository today, before touching anything historical. The migration fails most often because it begins with the backfill, exhausts the volunteers, and never reaches present-day practice.
2. Freeze the wiki space to read-only within two weeks. Two writable sources of truth is the actual failure mode, and it appears immediately rather than later. Read-only keeps the history available while removing the ambiguity about where to write.
3. Backfill only what still constrains code. Walk the current architecture, not the wiki index: for each significant component, ask whether anyone can explain why it is that way. That list is normally 15 to 30 records, not 300 — roughly a tenth of the page count, because most wiki pages are status updates and meeting notes.
4. Write backfilled records as reconstructions, marked as such. Status accepted (reconstructed 2026-09), context written from what the code and the incident history show, alternatives left empty where nobody remembers. A reconstruction that invents a rationale is worse than a gap.
5. Link, do not copy. Each new record points at the archived wiki page. The archive stays as evidence; the repository holds the position.
6. Put the index in the repository README and make the first line of every record its date and status, so a directory listing answers "what did we decide recently" without opening anything.

Where it diverges and how you would know

The divergence is silent: someone updates the archived wiki page because it is still top of their search results. Detect it by making the wiki space genuinely read-only rather than "deprecated" — a notice at the top of a page stops nobody. The second divergence is a record superseded in the repository while a chat thread continues to carry the old decision as current; the defence is that a superseded record keeps its file and gains a forward link, so a search hits the chain rather than a dead end.

The point of no return

Read-only on the wiki. Everything before it is reversible — you can abandon the repository experiment and lose nothing. After it, the organisation has one place to write, and turning back means re-teaching the habit twice, which the team will not do a second time. Sequence the freeze after step 1 and never before.

What it actually costs

Roughly an afternoon a week for one person over six to eight weeks, most of it in step 3, plus about an hour per reconstructed record. The recurring cost afterwards is under an hour per decision. The saving is real but slow: it shows up as shorter onboarding and fewer re-litigated arguments, not as a metric anyone can put on a slide this quarter.

When this is the wrong answer

If the team is fewer than about eight people and everyone who made the decisions is still there, this is process without a beneficiary. Move the records when the first person who made them leaves, or when a second team starts depending on the choices — that is the moment the cost of reconstruction becomes real. The failure mode of migrating early is a tidy directory of records nobody reads, which then gets cited as evidence that records do not work.