Six years of architecture decision records live in a wiki - about 700 pages numbered ADR-0001 upward in one global sequence, with roughly 40% superseded and not marked as such. You are moving them next to the code, one folder per service, with delivery continuing throughout. Give the sequence, and name the step after which rollback stops being cheap.

The sequence

1. Freeze new wiki records and repoint the template at the repository. One day of work. Everything written from now on lands in the right place, which stops the corpus growing while you move it. Fully reversible.
2. Export all 700 to markdown mechanically, preserving the wiki page id as a front-matter field and leaving a permanent redirect from every old URL. No human judgement yet. Reversible: the wiki is still authoritative.
3. Assign an immutable identifier that is not the position in a sequence - a date plus a slug, for example 2021-06-14-vitess-for-sessions - and keep the old number as a legacy-id field. This step is cheap now and impossible later.
4. Classify without moving. For each record, name the owning service. Expect 15% to 25% to have no owning service - cross-cutting decisions about authentication, currency handling, logging - which need a platform repository rather than being forced into whichever service happens to touch them.
5. Move only the live records. A record is live if its status is accepted and current code still follows it. On a six-year corpus that is around 60% of 700, so roughly 400 records move and 300 go to an archive folder with a pointer rather than being rewritten.
6. Add the revisit condition and supersedes links to the live set only. Backfilling all 700 is a quarter of work that nobody reads.

Where the records can diverge

Between steps 2 and 5 the wiki and the repository both exist. The divergence is not in the text, it is in the link graph: a ticket, a code comment or a runbook that cites "ADR-0142" now has two resolutions. The detection is mechanical - grep the codebase and the ticket tracker for the ADR-\d+ pattern before you start, and you will find more references than anyone expects.

The point of no return

Step 5, if step 3 was skipped. Once a single global sequence is split across repositories, each repository's next record wants to be the next number, and within a month two services have an ADR-0231. Every link into the corpus then breaks silently, because numbering is positional and position is not portable across a split - the citation still resolves, to the wrong document. After that point you are not rolling back a migration, you are reconciling two numbering schemes by hand.

Doing step 3 first makes step 5 reversible: the identifier survives the move, so putting records back costs a git revert.

How long it really takes

Classification at five minutes per record is about 60 person-hours; the rewrite of 400 live records, even lightly, is the expensive half and runs to several hundred hours if anyone tries to improve them on the way. Do not improve them on the way. A straight move plus the status field is a quarter of the cost and delivers most of the value, which is that the next change to a decision arrives as a pull request beside the code.

When this is the wrong answer

Below roughly 100 records, or in an organisation with one deployable unit, the wiki is fine and the move buys nothing. The gain here is specific: a decision and the code implementing it change in one reviewed commit. Choose the move only if services are separately deployable and reviews already touch architecture; when neither holds, prefer leaving the corpus where it is, because you are then paying for a link graph and getting file management.