How Do You Migrate Ten Years of Pages Without Losing the Archive?

Ten years of publishing leaves a site with two kinds of pages: the ones somebody would notice going missing, and the ones nobody has opened since the year they were written. A migration treats both exactly the same way unless you deliberately stop it. That is the whole problem, and it is not a technical one.

The default plan is a spreadsheet of every URL with a tick box beside it. It looks responsible. It is also the most expensive way to run a content migration strategy, because it converts a judgement exercise into a transport exercise, and transport is the part a script can already do. The judgement is the part that needs a person with the authority to say no.

So the order we work in is: count, judge, map, move. Counting is tedious and cheap. Judging is uncomfortable and free. Mapping is the artefact everything else hangs off. Moving comes last, and by then it is mostly mechanical. Teams that invert the order end up with a website migration that carried every mistake of the last decade across intact, plus a few new ones nobody has names for yet.

Count before you plan anything

You cannot triage what you have not listed, and no single system holds the full list. Four sources each know part of it, and each is missing something one of the others holds.

• The CMS. Knows what was published, including the drafts, the near-duplicates and the pages that were never linked from anywhere.
• Analytics. Knows what people opened, and nothing at all about pages that were never instrumented or that predate the current tag.
• Search Console. Knows which URLs search still finds and still sends people to, including a few your CMS had forgotten it was serving.
• The server logs. Know what is being requested right now, by people and by crawlers: the PDFs, the old campaign URLs, the endpoints nobody put in a menu.

Reconcile the four into one sheet keyed on URL. Expect the total to be considerably larger than anyone guessed, usually because of paginated archives, tag pages, attachment pages and a long tail of URLs generated by a plugin somebody removed years ago without cleaning up after it.

The columns that earn their place

A migration sheet becomes unusable past about eight columns, so choose them for the decision they support rather than for completeness. We keep: the URL, the page type, the date of the last meaningful edit, entrances from search over twelve months, the number of inbound internal links, whether any external site links to it, a named owner, and the decision. The last two are the columns people skip, and they are the ones that make the sheet usable rather than merely accurate.

A content migration strategy is mostly subtraction

Here is the position this piece defends: deciding what not to migrate is the highest-value hour in the entire project, and it is almost always delegated to whoever happens to be doing the moving. It should not be. Every page you carry forward is a page somebody has to re-model, re-check, re-link, re-approve, and then maintain for another decade.

A thousand pages of which four hundred are dead is not a thousand-page site. It is a six-hundred-page site carrying four hundred pages of drag on every future decision: every navigation rework, every content model change, every audit, and every time someone asks whether the site says two different things about the same subject. It usually does.

The counter-argument is real and worth stating plainly. A page with no traffic is not automatically a page with no value. Legal notices, documentation for a version somebody still runs, and pages that exist to answer one specific question well may be opened rarely and matter enormously when they are. Traffic is a signal, not a verdict. Which is exactly why the retire decision needs a person rather than a threshold in a formula.

A migration is the one moment when removing a page is cheap. After launch it becomes a conversation about who wrote it.

Triage: keep, merge, retire

Three outcomes, one decision per row, no maybes. A maybe pile is a keep pile with extra steps, because nothing is ever moved out of it. Work through the sheet in a single pass and force every row into one of the three.

Run the pass as a pair: one person who knows the numbers, one who knows what the business actually sells, and a standing rule that neither of them can retire a page alone. That is slower than one person with a spreadsheet, and it is the only version that survives contact with the colleague who wrote the page. The pair also catches the failure a threshold cannot see, which is the page with almost no traffic that answers the question every sales conversation ends with.

Merging without losing the signal

Merging is where the value sits and where the mistakes hide. Two thin pages on one subject usually become a single better page, and that page inherits the internal links and the external ones from both. What it must also inherit is the specific wording that made the weaker page findable. Merge the pages, keep the sentences. A merge that rewrites everything in the survivor’s voice quietly discards the exact phrasing that was matching a query nobody thought to check.

Retiring with a destination

Retired does not mean deleted and forgotten. It means the URL stops serving content and starts pointing somewhere honest: the nearest page answering the same need, or the section it belonged to. Sending everything to the homepage is deletion with worse manners, and both people and crawlers read it that way. Where there is genuinely no successor, a clean gone response tells the truth faster than a redirect that resolves nowhere useful.

The map is the artefact

The map is one file: old URL, new URL, redirect type, decision, owner. It decides whether the migration holds, and it should exist before anybody builds a template. Generate the redirect rules from it, never by hand — a hand-maintained redirect list drifts from the sheet inside a week, and then nobody can say which of the two is true.

Three rules keep a map honest. One row per old URL, so nothing is silently dropped. No chains: if a page moved twice, the map records the final destination and not the intermediate one. And every row is testable, which makes the map the test fixture as well as the plan. You run the whole file against the new site and count the rows that do not return what they promised.

Where the content lands matters as much as where it came from. Content stored as typed fields can be re-rendered into whatever the new templates need. Content stored as a wall of pasted markup can only be reformatted by hand, page by page. That is the argument our parent company makes in Git-based CMS or API-based CMS, and a migration is the week it stops being theoretical. A structured workspace such as Acrosite takes one approach to that: editors work in fields, the workspace generates the files, commits them and triggers the configured deployment, so each migrated page arrives as a reviewable change rather than an opaque paste.

What breaks silently

Loud failures get fixed on launch day. The ones that cost you are the failures nobody sees for six weeks, because nothing errors and every page renders.

• Redirect chains. Old URL to interim URL to final URL still lands in a browser, so it survives a spot check. It is slower for people and weaker for crawlers than the single hop you could have written instead.
• Query strings and anchors. Filtered listings, tracking parameters and deep anchors are usually absent from the map because the crawler normalised them away. Somebody’s bookmarked link stops arriving at the right place.
• Assets that moved without their pages. PDFs, images and downloads carry links from other sites. They rarely appear in a CMS export and almost never appear in a page inventory.
• Alt text and captions. Media libraries move the file and drop the metadata more often than anyone expects. The images arrive; the descriptions that made them accessible do not.
• Canonicals and structured data. These live in templates, so a single wrong default applies itself to thousands of pages at once, and it looks identical to a correct one until something tests it.
• Links inside body copy. They still point at old paths. The redirects cover them, so nothing breaks visibly, and every internal journey quietly runs through an extra hop.

That last one deserves a dedicated pass: rewrite the links inside the content rather than relying on redirects to cover them forever. On WordPress it sits with the other platform-level fixes that get postponed indefinitely because the site appears to work. It does appear to work, right up until somebody prunes the redirect file to make the config readable again.

Phasing the cutover

Big-bang migrations are defensible for small sites and reckless for large ones, and the reason is diagnosis rather than risk appetite. When several hundred pages move at once and the numbers move with them, you cannot tell which change caused what. A phased move buys you attribution, which is the only thing that lets you correct course while correcting is still cheap.

1. Move one template end to end. Pick the page type with many instances and low risk. Build it, migrate a handful of pages into it, and let the whole pipeline run once before it has to run a thousand times.
2. Migrate by template, not by section. Sections mix page types and force you to solve every problem at once. Templates group the work by the thing that actually varies.
3. Publish the redirects on the launch deploy. Not the following morning. The window between the switch and the redirects is the window in which every old URL returns nothing at all.
4. Swap the sitemap in the same release. It should list only canonical, live URLs on the new site. Leaving the old file in place invites crawlers to keep re-checking pages you retired on purpose.
5. Retire last. Hold the retire batch until the keep and merge batches are stable. If something turns out to have been miscategorised, you want the original still standing.

The six weeks after the move

A migration is not finished at launch. It is finished when the numbers stop moving and you can explain the ones that moved. Run the full map as a test on launch day and again a week later. Crawl the new site end to end and compare the URL list against the keep and merge columns. Watch entrance URLs week over week rather than totals, because a total hides a page that vanished behind a page that grew.

Three checks are worth scheduling rather than remembering. A full crawl at launch and another at four weeks, so the two URL lists can be diffed against each other. A run of the entire map, which either passes or names the exact rows that did not. And a deliberate look at the merged pages, because a merge is the one decision in the set that can be wrong in a way the redirect hides completely: the URL resolves, the page loads quickly, and the sentence the visitor came for was edited out during the rewrite.

Keep the map and the inventory somewhere with a history. When a page turns up missing in month four, and one will, the useful question is not where it went but who decided, and that answer only exists if the decision was written down beside the row. This is the ordinary, unglamorous case for version control on marketing content: the sheet is content, the decisions are content, and both outlive the project that produced them.

Where we would start

Given one week before a migration project kicks off, spend it on the inventory and the triage rather than on the platform evaluation. The platform question is interesting and reversible. The archive question is boring and permanent, because the pages you drop without noticing are the ones you will never think to look for.

The condition under which this advice reverses: a genuinely small archive. Under roughly two hundred pages, triage costs more meeting time than it saves engineering time, and the honest move is to carry everything across and prune afterwards with real data from the new site. The subtraction argument is about archives large enough that nobody can hold them in their head. Below that line, judgement is cheaper applied later.

Everywhere else, the retire list is the deliverable that pays for the project twice: once in the work you do not do, and again in every future decision made against a smaller, truer site. If you want a second pair of eyes on an archive before it moves, send us the page count and the platform, and we will tell you which of the four counts to trust first.