You decide a page's fate before you touch a single template by grading it against evidence you already have: how much traffic it pulls, how many sites link to it, whether it earns anything, whether three other pages say the same thing, and whether a machine can still read it. Score that in a spreadsheet and every page falls into one of three verdicts. Migrate it as-is. Rewrite it. Kill it. No sandbox required.
Here is why I keep hammering this. The last few migrations I watched go sideways all failed the same way: nobody decided anything until the content was already sitting in the new system. The team would load a page into the shiny new editor, squint at it, argue for twenty minutes, and move on to the next one. Three thousand pages at twenty minutes each. You do the math (I did, and then I lay down for a while).
Your site is an inbox you stopped reading in 2016
Open your full URL inventory and look at it the way you look at your inbox after a week off. Thousands of items. Most of them you will never touch. A few are load-bearing. Several are duplicates of each other. And a surprising number are notifications from a system that no longer exists, quietly piling up in the dark.
You do not read every email to clear an inbox. You archive the ones worth keeping exactly as they are, you flag the few that need a real reply, and you delete the rest without ceremony. Migrate, rewrite, kill. Same three gestures, same ruthlessness. The only difference is that nobody cries when you archive a newsletter, whereas somebody in marketing will absolutely fight for the 2019 press release with eleven lifetime visits.
What you score before you grade anything
The verdict is only as good as the signals under it, and the good news is you can pull every one of these without the new platform existing yet. Organic and referral traffic over the last twelve months, not last month. Inbound links from other domains, because those are the hardest thing to earn back and the easiest thing to lose in a bad redirect. Any conversion or revenue the page touches. How many other pages on your own site overlap with it (the duplication that quietly cannibalises your own rankings). When it was last meaningfully updated. And whether a machine, a crawler or an answer engine, can actually parse the thing or just finds a wall of JavaScript and a spinner.
That last one matters more every quarter. If an AI assistant can't read the page, it can't quote you, and increasingly that is where people get their answer before they ever see a blue link.
The three verdicts, on paper
| Verdict | What it means | Score it when |
|---|---|---|
| Migrate | Move as-is. Preserve URL, redirect, and metadata. | It earns traffic, links, or money, and it reads cleanly. |
| Rewrite | Keep the slot, redo the content before or after the move. | The topic still matters but the page is thin, stale, or duplicated. |
| Kill | Do not rebuild. Redirect to the nearest living relative or let it 410. | No traffic, no links, no revenue, and nobody will miss it. |
Notice that kill does not mean the URL simply vanishes. A page with zero traffic can still hold a link from a government site or an old partner, and dropping that link into a 404 is how you leak authority you spent a decade building. Killed pages still get a forwarding address. You are not burning the letters, you are telling the post office where the person moved.
The rewrite pile is where the honesty lives
Migrate and kill are easy. The rewrite pile is where teams lie to themselves. Every page nobody can bring themselves to delete gets dumped there, and then the rewrite backlog becomes a graveyard with better lighting. A rewrite only counts if someone's name is next to it and a date is next to that. If you cannot assign it, it is not a rewrite. It is a kill wearing a nice coat.
Be honest about capacity, too. If your team can realistically rewrite forty pages before cutover, your rewrite pile has forty pages in it. Page forty-one is a migrate (ship it as-is, fix it later) or a kill. Pretending you will rewrite four hundred is how the easy half of the budget eats the hard half.
Why a spreadsheet beats a sandbox
Deciding in the build environment feels like progress because you can see the page. It is a trap. You are making a strategic call (does this content deserve to exist) while staring at a tactical problem (why is this image floating). Separate them. Score the whole inventory on paper first, get the three piles agreed and signed off, and only then open the new system to execute a decision that is already made.
This is the part we built a crawler to do, because scoring thousands of URLs by hand on traffic, links, duplication, and machine-readability is exactly the kind of tedium software should eat. You can walk the migration scoring approach yourself with your analytics export and a link tool and a free afternoon. The method does not care what runs it.
So what would I actually do?
I would refuse to open the new CMS until the inventory is scored and the three piles are signed. Not as a best practice. As a hard gate. Every migration I've seen run late ran late because the content decisions and the build happened in the same room at the same time, and the two jobs poisoned each other. Decide on paper, build from the plan, and let the editor be a place where you execute verdicts rather than argue them.
Your inbox has thousands of emails in it right now and you are not afraid of it, because you already know which three you need to answer. Your site is no different. You just haven't opened it yet.