A website content migration plan: decide what to keep, change and leave behind

Your new website structure is taking shape. The old site still contains years of service pages, news, downloads and information maintained by different teams. Moving everything across may feel like the easiest way to keep the project progressing.

A content migration plan gives you a more deliberate approach. It records what each item does, whether it remains useful and what should happen to it. That helps editors, designers and developers work from the same decisions as the new site takes shape.

Build an inventory people can work with

Start with a list of existing pages and files, using a site crawl, your content system and the knowledge of the teams who maintain them. Include important downloads, forms and content that lives outside the main navigation.

Add the owner, purpose and current location of each item. Bring in available search, visit and enquiry evidence, while recording its period and limitations. A rarely visited page may still answer an essential question. Someone needs to assess its role before making a decision about it.

Our earlier article on putting content at the centre of a website project explains why this work belongs within the project plan. The migration register turns that principle into specific decisions about the material you already hold.

Give each item an editorial decision

We recommend four starting categories. Use them consistently, and add a short reason for every decision.

• Retain: The information serves a current user need and remains accurate. Identify any formatting or adaptation required for the new site.
• Rewrite: The need remains, but the content needs a clearer explanation, updated facts or a different structure. Name the writer and approver.
• Merge: Several items answer closely related questions. Agree the destination, the information it must preserve and the owner of the combined page.
• Retire: The item no longer has a useful public role. Check any organisational, contractual or record-keeping requirement with the responsible colleague before removing access.

If the evidence is insufficient, mark the decision as unresolved and assign someone to investigate it. A default “retain” can hide a substantial amount of work later, particularly when the content needs a new layout or more careful review.

Use this migration register

Create a shared document with one row per item and these fields:

1. Current URL and title: Identify the source precisely, including a file location where relevant.
2. User need: State the question or task the content supports, with the evidence you hold.
3. Decision and reason: Record retain, rewrite, merge or retire, or the question preventing a decision.
4. Destination: Identify the approved page or section on the new site. Keep any proposed URL clearly marked until it is agreed.
5. Work and owner: Describe the editing, asset preparation or specialist review required, with a named person responsible.
6. Approval state: Record who has checked the content and which version is approved for migration.
7. Technical handover: Flag changed URLs, downloads, links or functionality that the developer and search specialist need to assess.
8. Release check: State what someone will verify on the new site and who will confirm it is complete.

Test the decisions against a real journey

Imagine an organisation with three pages explaining different versions of the same service. This is an illustrative example. Two pages contain useful details; the third describes an offer that has ended.

The team might combine the current information into one service page, rewrite the eligibility explanation and retire the ended offer. Before approving that plan, they check whether visitors still need an explanation of the change and whether any external links point to the existing pages.

That produces a clearer handover than simply labelling the folder “old content”. The editorial team can explain what must remain available, while technical specialists can determine how the existing addresses should behave.

For Interfix, our website work included a new sitemap and a clearer distribution of content across relevant pages, alongside a dedicated case-study area. The Interfix website case study shows why the arrangement of information deserves attention during a redesign.

Connect editorial decisions with the technical plan

Content decisions and URL behaviour need to be reviewed together. Google’s site-move guidance recommends mapping existing URLs to their new destinations, updating internal links and implementing appropriate redirects when addresses change.

Give your developer and search specialist the approved register before implementation. They should confirm the treatment of changed or removed URLs, canonical addresses, downloadable files and the sitemap. Agree how they will test the implementation and review search data after launch.

Some content changes can affect visibility while search engines process the site. Keep a dated record of the old content and approved decisions so the team can investigate any unexpected change with useful context.

Check the migrated experience

Before launch, review representative pages in their new layouts. Check headings, links, images, downloads and the information needed to complete a task. Ask the content owner to confirm accuracy, and identify who will maintain the material afterwards.

Our website design and development work connects content structure with the experience people need. Bring us your current site, proposed structure and unresolved content decisions. We can help you define a manageable route from existing material to a useful new website.