Content migration

What content migration is

Content migration is the physical move of your existing pages onto a new website: rebuilding each page in the new system, applying a redirect for every old address, and then checking the result page by page. It is the work that happens on and around launch day, and it is judged on whether the new site keeps the traffic and the inquiries the old one had.

It is not the plan. The plan is a content migration plan, written weeks earlier, and it is where the decisions live: what moves, what is merged into something better, what is quietly retired, and what each dead address should redirect to. A sensible project buys the plan first and the move second. Without the plan, the move becomes a series of judgement calls made at speed by whoever happens to be at the keyboard, which is how sites lose pages they meant to keep.

When you need it

Three situations, mostly. You are rebuilding on a new platform and the pages have to be re-entered rather than lifted across. You are changing your addresses — a new domain, a new structure, dropping a language prefix — and every old address needs somewhere to land. Or you are merging two sites after buying a business, which is both at once.

You do not need this if the new site is being built by a developer who has quoted for the content move as part of their work, and can show you the redirect map they intend to use. What you may want instead is a second pair of eyes afterwards: a link sweep and a check of the pages that matter most.

What the work covers

• The rebuild. Each page that is moving, entered into the new system using the new templates, with its headings, images, tables, downloads and internal links in place. Formatting is redone to match the new site rather than pasted in and left looking foreign.
• The redirect map. A row for every address the old site had, with the new address it should go to. Where a page is being merged, the redirect points at the page that absorbed it. Where a page is being retired, it points at the nearest useful parent, not the home page.
• Internal links. Every link between your own pages repointed at the new addresses, so no reader is bounced through a redirect to get from one of your pages to another.
• Metadata and images. Titles, descriptions and image text carried across rather than left blank, which is the single most common casualty of a rebuild.
• The checks. A pass on the staging site before launch, and a second pass in the week after, comparing the live site against the list of what was supposed to have moved.

What you get

The rebuilt pages. Live on the new site, formatted, linked and checked on a phone as well as a desktop.

The redirect map, applied and verified. A spreadsheet with one row per old address, its destination, and a column showing that it was tested after launch and behaves. Your developer or host installs the redirects; I produce the map, confirm each one works, and chase the ones that do not.

A launch-week check. A short document written seven days after launch: which pages are being visited, which old addresses are still being requested and where they now land, and anything that needs fixing. This is the part that catches the quiet losses while they are still cheap to fix.

A list of what did not move. Every page deliberately left behind, with the reason. It is the document you will want in six months when somebody asks what happened to a page.

A worked example

An illustration, not a client. A Saskatoon equipment dealer moves from a fourteen-year-old custom site to a standard platform. The old site has roughly four hundred addresses: ninety proper pages, two hundred and forty product entries, and the rest old news items and duplicates the owner did not know existed.

The plan, bought first, decides that eighty-two of the ninety pages move, the product entries are rebuilt from the supplier feed with thirty of them written properly by hand, and the news items are merged into six pages by year. The move then follows the plan without re-arguing it. The redirect map has four hundred and eleven rows; the six busiest old addresses are tested first, on launch morning, before anything else. The launch-week check finds nineteen addresses redirecting to the wrong place because of a pattern rule the host applied too broadly, and one product category that never got its description. Both are fixed inside two days, which is the whole point of looking in that first week.

How it runs

1. A half-hour call. What the new site is, who is building it, how many addresses the old site has, and whether a plan exists. No charge.
2. A fixed price in writing. Based on the number of pages moving and how much rebuilding each needs, agreed before anything starts.
3. The inventory and the map. Around a week. Every old address listed, matched to a destination, and signed off by you before a single page is rebuilt.
4. The rebuild. Two to five weeks on a staging site for a few hundred pages, working alongside whoever is building the site, with a weekly note on progress.
5. Launch and the week after. Redirects tested on the day, the busiest addresses first, then the seven-day check and the fixes it produces.

What it costs

Quoted in CAD after the half-hour call, and not before, because a two-hundred-page move and a two-thousand-page move share only a name. The price is driven by how many pages need real rebuilding rather than straight re-entry, how clean the old site's structure is, and whether the redirect decisions have already been made. The pricing page shows the four ways of working so you can see the shape of the thing. The figure is fixed in writing before any work starts, and if the scope grows you get a new number to approve rather than a surprise on the invoice.

What happens next

Three things follow a move. A first link sweep about a month later catches the links that broke in ways nobody predicted. The pages that were carried across but are visibly tired go for an update to the pages that used to earn, which is cheaper than writing new ones. And the new site is the natural moment to put a review date against every page so the next rebuild is not another archaeology project. None of that is assumed. The move is a complete piece of work, it ends with a site that behaves, and nothing further is committed.