You can decide whether a page gets to migrate, gets a rewrite, or gets killed using four numbers, all of which you can pull into a spreadsheet before anyone spins up a single template: how many people actually find it, who links to it, whether it earns the business anything, and whether it's a duplicate of the page next to it. Get those four columns filled in and the verdict practically writes itself. The template can wait. The judgement can't.
Here's the thing nobody tells you before the first migration. Somewhere in a kickoff meeting, someone with a calm voice and a full calendar says "let's just migrate everything and clean up later." And everyone nods, because everything sounds safe. Everything is not safe. Everything is how you drag 8,000 pages into a shiny new house when maybe 1,200 of them ever get a visitor, and the rest are drafts named "draft-final-v2," a 2014 press release about a rebrand, and forty near-identical location pages that differ only in the phone number.
Think of it as auditions, not a moving day
Forget boxes for a second. You're casting a show. The new site is the stage, and it hasn't been built yet, which is exactly why now is the moment to hold auditions. Every page walks out, does its thirty seconds, and you decide: you're in, you're in but you need new material, or thanks, we'll call you (we won't).
The beautiful part is that you don't need the stage to run the auditions. You need the performances on tape. That tape is your analytics export, your backlink data, your CRM, and a crawl of what's actually published. None of that lives in the CMS you're leaving or the one you're joining. It lives in a spreadsheet you can build today.
And auditioning first solves the thing that quietly wrecks migration timelines: developers building components for pages that should never have made the cut. You do not want to spend a sprint recreating a bespoke layout for a page that got eleven visits last year, nine of whom were you, checking whether it still existed.
The four numbers that decide it
Pull these for every URL. Traffic first: organic sessions and impressions over the last twelve months, not thirty days, because a quarterly report page looks dead in March and beloved in July. Then links: external backlinks pointing at the URL, plus how many internal pages link to it (an orphan with zero internal links is already half-dead). Then value: does the page sit on a path to a conversion, a lead, a signup, a sale? Then uniqueness: is this the only page saying this thing, or one of forty saying almost the same thing?
Now you sort. The logic isn't clever, and it doesn't need to be.
| Verdict | What it means | The signals that trigger it | What happens next |
|---|---|---|---|
| Migrate | Moves as-is, mapped 1:1 | Real traffic, earned backlinks, or clear business value, and the content still holds up | Gets a template, gets a redirect, gets QA'd carefully |
| Rewrite | The URL earns its spot, the content doesn't | Strong links or rankings pointing at thin, dated, or duplicated content | Keep the URL and its equity, replace what's on it before or after cutover |
| Kill | Doesn't come across | No traffic, no links, no value, or a near-duplicate of a stronger page | Consolidate into a survivor and 301 to it, or 410 if truly nothing points there |
Notice that "kill" almost never means "delete and shrug." A killed page with even one inbound link still needs somewhere to send that link, or you've turned an asset into a 404. Killing is a redirect decision as much as a content one, which is why you do it on paper, calmly, and not at 2am the night of launch.
Where the model lies to you
The scorecard is honest about pages that stand alone. It's a terrible liar about pages that don't stand at all. A hub page might show modest traffic of its own while being the only reason five high-value pages get discovered. Kill it and you don't lose one page, you orphan six. So before you trust any "kill," check what links out of the page, not just in.
Freshness is the other trap. A page with zero sessions this year might be a landing page for a product you relaunch next quarter. The number can't see the future in your roadmap. That's the one place I'd let a human overrule the spreadsheet, and only that place.
This is roughly the work our pre-migration scoring automates: crawl the site, join it to the traffic, links and duplication signals, and hand back a migrate/rewrite/kill column with the reasoning attached. Not because a spreadsheet can't do it. Because on 8,000 rows, a spreadsheet is where the honest intentions quietly go to die.
So what would I actually do?
I'd score everything before I let anyone open the new CMS, and I'd hold the line on it. Most sites can kill or consolidate a third to a half of their pages and lose nothing a real person misses, and every page you don't migrate is a template you don't build, a redirect you don't test, and a QA pass you don't run twice. The teams that migrate everything aren't being thorough. They're being scared, and they're paying for it in launch delays and a new site that's just as cluttered as the old one, only slower to load and harder to search.
Run the auditions first. Build the stage for the acts that made it. And when someone says "let's just migrate everything and clean up later," you now know what "later" is: never, and it costs six months of crawl budget.