Content migration plan

What a content migration plan is

A content migration plan is the document written before a site is rebuilt or moved to a new platform. It says which pages come across, which are left behind, where every old address points afterwards, and in what order the whole thing happens. It is produced weeks before launch, and it is the thing the developer works from on the day.

It is a plan, not the move. The moving itself — entering the content, checking it, setting the redirects live — is content migration, and it can be done by your developer, your agency or by me. What is bought here is the decisions, in writing, made before anyone starts building.

When you need one

You need one whenever the addresses on your site are going to change: a redesign that restructures the navigation, a move from one platform to another, two businesses merging their sites, or a shop rearranging its categories. If the addresses are staying exactly as they are, you do not need this at all.

The timing that works is a plan written before the new site is designed, not after it is built. A plan written afterwards is a rescue, and by then the decision about what to carry across has already been made by whoever happened to be doing the copying.

You do not need one for a site of a dozen pages that one person can map on paper in an afternoon. Spend the money on a content audit instead, which will at least tell you whether those dozen pages are any good.

What goes in it

• The full address list. Every address the current site answers on, including the ones nobody remembers: old campaign pages, downloadable files, images that other sites link to directly, and the versions with and without a trailing slash.
• The carry list. What moves, and whether it moves as it is or gets rewritten on the way. A rebuild is the cheapest moment there will ever be to fix a page, because somebody is already touching it.
• The drop list. What does not come across, and why. This is the most valuable page in the document and the one that saves the most money, because every page carried across is paid for twice.
• The redirect map. Old address in one column, new address in the next, one row each, with nothing pointed at the home page unless there is genuinely nowhere better. A redirect to the home page is a dead end with a friendly face.
• The order and the freeze. What happens in which week, and the date after which nothing new is published on the old site. Without a freeze date the two sites drift apart and something gets lost between them.

What you get

The redirect file. A spreadsheet your developer can work from directly, in the format their platform expects. This is the deliverable that matters most on launch day, and it is the one most rebuilds turn out to be missing.

The plan document. Six to ten pages: the carry and drop lists with reasons, the freeze date, the running order, and the named risks. Written for the person paying for the rebuild rather than for the developer.

The launch-day checklist. One page of checks to run in the first hours and again after a week: addresses that should redirect and do not, pages that came across empty, forms that no longer send anywhere, and links inside the content still pointing at the old structure.

A worked example

An illustration. A dental practice in Victoria is moving off a ten-year-old site, and the new design has six service pages where the old one had twenty-two. The address list turns up 340 entries, of which 90 are images linked to from a directory the practice had entirely forgotten about.

The plan carries eleven pages unchanged, rewrites six on the way across because they are being folded into the new service pages anyway, and drops 130 blog posts and every date archive. Each of the twenty-two old service addresses is mapped to whichever of the six new pages answers the same question, and none of them is sent to the home page. The freeze date is set for the Friday before launch. On the day, the checklist catches two things: the booking form on three of the new pages points at a test address, and a page for a treatment the practice no longer offers had been carried across by accident. Both are fixed inside an hour.

How it runs

1. A half-hour call. What is changing, who is building it, and when launch is. The earlier this call happens, the cheaper everything after it becomes. No charge.
2. Access. A crawl of the current site, read-only access to your analytics, the structure of the new site if it has been settled, and a conversation with whoever is building it.
3. The plan. Five to ten working days, depending on how many addresses there are and how far the new structure has been decided.
4. Handover. The plan and the redirect file go to you and to the developer together, with a call so that all of us agree what the file means before launch week rather than during it.

What it costs

Quoted in CAD as a fixed price after the half-hour call and agreed in writing before anything starts. The size depends on the number of addresses and on how much rewriting is done on the way across. It is not one of the four standing ways of working shown on the pricing page, though it often sits inside a larger project alongside them.

What happens next

The plan is usually written just after a pruning pass, because deleting before you move is a great deal cheaper than moving before you delete. The pages marked for rewriting on the way across are the natural moment for consolidation. After launch, a link check a fortnight later catches the redirects that were set wrong and the internal links still pointing at the old structure. None of that is assumed. The plan is a complete piece of work, and its whole purpose is that the rebuild loses nothing that was earning.