Four team wikis holding about 1400 pages between them are being consolidated into one documentation site for 300 engineers. Analytics show 43 pages serve over half of all reads. Which sequence do you run?

The sequence

1. Classify by read pattern, not by owner. Pull the top pages by views and, separately, the top search queries that returned nothing. The 43 pages carrying half the reads plus the on-call and integration pages are the set that matters; call it 60 to 80 pages.
2. Rewrite, not copy, those pages onto the new site. A page read under pressure is worth an hour of editing; a page read twice a year is not.
3. Redirect the old URLs for exactly those pages, preserving anchors where you can. Links to documentation live in tickets, runbooks, code comments, alert annotations and browser bookmarks, none of which you control, so a moved page without a redirect is a page that disappears during an incident.
4. Freeze the remaining pages read-only with a dated banner naming the new site and the owner to ask. Frozen and dated beats copied and unmaintained, because a reader can price staleness they can see.
5. Delete nothing for at least two release cycles. Keep the old corpus searchable.

Where it can diverge, and how you would know

The failure is a page that exists in both places with different content, which is worse than either. Guard it by making the old copy read-only at the moment the new one goes live, in the same change. Watch two signals: 404s and redirect misses on old URLs, and search queries on the new site returning no result, which is your list of pages you wrongly classified as archive.

Twilio's published platform SDK support policy is a useful precedent for the retention decision: the previous major version is supported for 12 months after the new one becomes generally available, while that version's documentation stays online for 24 months. The documentation commitment deliberately outlasts the software's, because people run old versions and read old pages long after support ends.

Why the other options fail

• Copy all 1400 pages then redirect and delete. Tempting because it is one change and loses nothing. It imports 1300 pages of staleness into a site whose value proposition is that its pages are current, and it doubles the surface anybody must now maintain. It is the right answer only when the old system is being switched off on a fixed date outside your control.
• Freeze and migrate on request. Reasonable-sounding demand-driven triage, and it puts the work in the path of someone who needs the page now, usually mid-incident. Requests also under-represent pages read by people who will not ask, such as new joiners and external teams.
• Publish alongside and migrate on touch. The standard answer for code, and it fails for documentation because nobody touches archive pages. Two years later there are five homes for documentation instead of four, and the new site is the least complete.

The point of no return

Deleting the old wikis. Before that, every mistake is recoverable by pointing a redirect somewhere else. Delay it until the 404 rate on old URLs is near zero for a full month.

When this is the wrong answer

Below roughly one team and a few hundred pages, consolidate by hand in an afternoon and skip the analytics. The read-concentration argument only pays when the corpus is large enough that you cannot read all of it, and when enough links exist outside your control to make redirects necessary.