Blog

Read the X-Ray, Then Decide: Migrate, Rewrite, Kill

· 6 min read · By the Replatform Radar team

Before you touch a single template, you can sort every page on your site into three buckets: migrate the pages that still earn their keep exactly as they are, rewrite the ones with good bones and tired content, and kill the ones nobody visits and nobody links to. You do it by reading each page's signals first: organic traffic, inbound links, duplication, whether anything links to it internally, how stale it is, and whether a machine can actually read it. The scoring happens in a spreadsheet. The building happens later, and only for the survivors.

Here's the moment that kills more migration budgets than any plugin ever has. You've locked the cutover date. The design team is lovingly rebuilding a component for a service page that gets four visits a month (three of which are bots, and one of which is you, checking it still exists). Multiply that by a few thousand pages and you've spent the whole quarter restoring furniture into a house nobody was going to live in.

So let's not do the surgery first.

Read the scan before you open the patient

A good surgeon does not walk into theatre and start cutting to see what's wrong. They read the scans. They look at the X-ray, the bloodwork, the chart, and they decide what the body in front of them actually needs before a scalpel comes anywhere near it. Some patients are healthy and just need to be moved to the new ward. Some need a procedure. And some, bless them, are long past saving, and the kindest thing you can do is not pretend otherwise.

Your pages are the patients. Your crawl is the scan. Migrating a site without reading the scan first is how you end up carefully transplanting a tumour into a brand new building.

The good news is that the signals you need are all measurable, and none of them require the new platform to exist yet. You can pull most of them from analytics, your backlink tool, a crawler, and your search console. That's the whole point: this is a paper exercise. You are grading the body before you book the theatre.

What the scan actually tells you

Six readings do most of the work. How much organic traffic a page earns, how many external sites link to it, whether its content is duplicated elsewhere on your own site, whether anything internal links to it (an orphan is a page nobody can walk to), how long it's been since anyone touched it, and whether a machine can parse it at all: clean HTML, real headings, structured data, not a screenshot of text pretending to be a page.

Lay those against the three verdicts and the pattern falls out fast.

ReadingLooks like migrateLooks like rewriteLooks like kill
Organic trafficSteady, meaningfulDeclining but realFlatlined for a year
Inbound linksEarns quality linksA few worth savingNone, or spam only
DuplicationUniqueOverlaps a stronger pageNear-identical to another URL
Orphan statusWell linked internallyReachable, barelyNothing links to it
FreshnessCurrent and accurateGood topic, stale factsAbout a product you killed
Machine-readableClean, structuredReadable, needs markupImage of text, PDF nobody opens

Most pages won't give you six green readings or six red ones. They'll be a mess of mixed signals, and that's fine. The verdict isn't a tally, it's a judgement. A page with no traffic but forty real inbound links is not a kill; it's a redirect target you'd be insane to delete. A page with great traffic that duplicates three others is a consolidate, which is just rewrite wearing a hat.

Why this has to happen on paper

Because the alternative is discovering your scoring halfway through a build, when changing your mind costs ten times as much. Decide a page is a kill in a spreadsheet and you type one word. Decide it after someone has rebuilt its template, mapped its fields, and wired its redirects, and you've paid for work you're now throwing away (and someone has to explain that in the retro).

Scoring on paper also forces the unglamorous question nobody volunteers for: who owns the kills? Deleting a page is a decision with a name attached, and the legal team, the product owner, and the person who wrote it in 2016 may all have feelings. Better to have that argument now, over a list, than at two in the morning during cutover.

This is the pre-migration scoring our own crawler is built to do: grade every page and asset on these signals and hand you the migrate / rewrite / kill plan before anyone opens a template. You can read how we frame the whole move at replatformradar.com/migrate. But you can run the first pass yourself, today, with the tools you already have.

So what would I actually do?

I'd kill more than feels comfortable, and I'd do it early. The instinct in every migration is to keep everything "just in case," and that instinct is how sites arrive at the new platform carrying a decade of dead weight into a shiny building with no more room than the old one. If a page has no traffic, no links, no internal path to it, and nothing current to say, it is not an asset you're preserving. It's a liability you're paying movers to carry.

The one place I soften is links. Never kill a page that other sites point to without a redirect waiting to catch it. Everything else, be ruthless with. Read the scan, make the call, write it down.

Because here's the thing about the patient nobody wants to let go of: the kindest cut is sometimes the one you make before the surgery even starts.

Questions and discussion

When you've scored pages for a migration, which bucket did you get wrong most often, and who ended up owning the kill decisions? I suspect the honest answer for a lot of teams is that nobody did, so everything got migrated by default. Tell me if I've got that backwards for how your last move actually went.
Steven Solano, who wrote this — and reads every reply

Loading discussion…

Want this analysis for your exact site before you migrate?

Request a scan →