Before you build one template in the new system, decide what earns a seat: migrate the page as-is, rewrite it, or kill it. You do that by scoring each URL against a fixed rubric on traffic, links, conversions, freshness, and duplication, then letting the numbers pick the verdict. Do it in a spreadsheet, not a staging environment. The point is to move less, not to move everything faster.
Here's the moment that always prompts this. Someone says, with total confidence, "we'll just migrate everything and clean it up later." Then the crawl comes back and "everything" is 14,000 URLs when the team swore it was 400. (It is always 400. It is never 400.) Now you're about to hand-build templates for a pile of pages, most of which nobody has visited since a previous logo.
So let me offer you the most useful chore I know: clean out the fridge before the movers arrive.
Why the fridge, of all things
Because a fridge is exactly the problem. Some things in there are sealed, in date, and travel fine. Some are half-used and genuinely good but need attention before they're worth packing. And some are a mystery container from a dinner you don't remember, quietly evolving in the back.
You do not solve this by building a beautiful new kitchen and then carrying every jar into it. You stand in front of the open door and make three piles. Pack it. Cook it tonight. Bin it.
Migrate. Rewrite. Kill.
The trap in a replatform is that the "new kitchen" is seductive. Templates are fun. Design tokens are fun. Sorting your own expired content is not fun, so people skip it and promise to do it "after launch." After launch never comes, and now the mystery container has a URL and a redirect and a place in your sitemap.
The rubric that makes the call for you
The reason to score on paper is that a rubric argues with the stakeholder so you don't have to. Nobody wins the fight about their favourite page in a meeting. They lose it, politely, to a column of numbers.
Pull five signals per URL, most of which you already have. Organic sessions over the last twelve months. Referring domains pointing at the page. Conversions or whatever downstream action matters. Last meaningfully updated date. And a duplication flag, because a shocking amount of any site is the same 300 words wearing different hats.
| Signal | Migrate (pack it) | Rewrite (cook it) | Kill (bin it) |
|---|---|---|---|
| Organic sessions, 12 mo | Steady, meaningful | Falling but real | ~0 |
| Referring domains | Has earned links | A few worth saving | None |
| Conversions / goal | Yes | Occasionally | Never |
| Last real update | Recent | Stale but fixable | Ancient, wrong |
| Duplication | Unique | Overlaps, could merge | Near-exact copy |
The logic is blunt on purpose. A page with traffic, links, and conversions travels sealed: migrate it, don't touch the words, preserve the URL. A page that clearly mattered but has gone stale, or that overlaps three siblings, is your "cook it tonight" pile: rewrite, consolidate, redirect the losers into the winner. And a page with no traffic, no links, no conversions, and a near-duplicate twin? That's the container in the back. You already know.
One number does most of the work here: a well-configured 301 passes effectively all of a page's ranking signals to its destination, which is what makes killing-with-a-redirect safe rather than reckless. Google has said as much for years. So "kill" rarely means "delete into a 404." It means point the arrow at something better and let the equity flow downhill.
The pile nobody scores
Pages are the easy part, because pages have analytics. The stuff that breaks a migration is the fridge door: the PDFs, the images, the old campaign landing pages that a partner still links to, the orphaned files no menu points at but Google indexed anyway. They don't show up in your CMS page tree, so they don't show up in your plan, so they cross over as a 404 you find three weeks after launch.
Score those too. An orphaned PDF with fourteen referring domains is not junk; it's a sealed jar you nearly left in the old kitchen. This is precisely the sweep a pre-migration crawl exists to do: find every asset, attach the signals, and hand you a migrate/rewrite/kill verdict per URL before the templates get involved.
Do it before the build, not during
Here is the whole argument for timing. Every page you kill on paper is a template you don't build, a redirect you don't test, a review you don't schedule, and a QA row that never exists. Culling before the build shrinks the entire project downstream. Culling after the build means you paid to move things you then delete, which is the migration equivalent of driving expired milk across town.
Score first. Argue with the spreadsheet. Then open the new kitchen.
So, my actual opinion, since you asked: default to kill, and make pages earn their way onto the truck. Most teams do the reverse. They default to migrate and make you justify a deletion, and that's how you end up with a gleaming new platform stocked entirely with mystery containers. Be the person who opens the fridge, holds something up to the light, and says the quiet part out loud: nobody has wanted this since 2019. Then bin it, forward its address, and go build a kitchen with room to move.