What to Decide Before Migrating Content to a New Website

A website migration can look like a straightforward publishing task. Export the old pages, import them into the new content management system, move the images and check that the links still work. In practice, that approach often transfers years of duplication, unclear ownership and outdated information into a cleaner design.

The difficulty is rarely the number of pages alone. Important content may also live in document libraries, campaign landing pages, staff profiles, forms, news archives and data feeds. Different teams may use the same words to mean different things, while apparently similar pages serve distinct audiences or legal purposes. If those decisions are discovered during the final import, the migration becomes rushed and expensive.

A strong content migration is an editorial, operational and technical project. It decides what the new website should contain, how that information will be structured, who is responsible for it and what evidence will prove that nothing important has been lost. Making those choices before the bulk move reduces launch risk and gives the new platform a much better starting point.

Begin with the purpose of the new website

Migration decisions need a clear definition of what the new website is expected to help people do. Without one, the safest-looking option is to copy everything. That protects the project from difficult conversations in the short term, but it leaves users navigating an estate designed around historic organisational structures rather than current needs.

List the main tasks and outcomes the website must support. These might include understanding a service, checking eligibility, making a purchase, submitting an application, finding technical guidance or contacting the correct team. Then identify the content needed for each task and the evidence that shows whether it is useful.

This does not mean deleting every page that is not part of a top journey. Organisations also need statutory information, policies, campaign material and specialist resources. The purpose exercise creates criteria for judging those items. It replaces “this page has always existed” with a clearer reason for keeping, changing or archiving it.

Build an inventory from every source

A crawler can provide a useful list of public URLs, titles, headings, status codes and file links. It cannot reveal everything the organisation considers part of its website. Draft pages, restricted sections, disconnected campaign sites, form confirmations, reusable content blocks and assets in the media library may not appear in a normal crawl.

Combine the crawl with exports from the current CMS and a short discovery exercise with content owners. Record the source, content type, URL, title, owner, audience, last meaningful review date and any dependencies. Dependencies can include embedded forms, third-party scripts, feeds, translated versions, downloadable files and links from printed material.

Keep the inventory usable. It should support decisions and tracking rather than becoming a perfect catalogue of every historical field. Give each item a stable migration reference so that the source, transformation decision, destination and validation result can be traced throughout the project.

Give every item an explicit destination

Each item should receive a decision such as keep, rewrite, merge, retire or archive. “Migrate” is not enough because it does not say whether the content can move unchanged or needs work first.

• Keep content that is accurate, useful and already suitable for the new structure.
• Rewrite content that serves a valid need but is unclear, inaccessible, out of date or written for the wrong audience.
• Merge competing pages that answer the same need or split one journey unnecessarily.
• Retire content that no longer has a purpose, while planning any redirect or user communication it requires.
• Archive material that must remain available for reference or record-keeping but should not compete with current guidance.

Define what each decision means operationally. A retired page might require a permanent redirect, a replacement message or no public destination at all. Archived information might belong in a document repository rather than the main navigation. Agreeing these rules keeps different reviewers from making incompatible choices.

Design the content model before the bulk import

Old websites often store information according to the limitations of the previous platform. A service description, contact details, eligibility rules and related documents may all be held in one large page field. Copying that field into another large editor preserves the same maintenance problem.

Define the main content types and their fields before migration. Decide which information should be structured, reusable or selected from a controlled list. A service record might have an owner, audience, summary, eligibility criteria, process steps, contact route and review date. An event or vacancy needs a different model.

The model should reflect how editors actually work and how users find information. Avoid creating structure simply because the CMS supports it. Too little structure makes consistency and reuse difficult; too much turns a routine update into a complex form that editors work around.

Test representative content against the model, including awkward cases. If the team tests only the cleanest pages, it may discover too late that an important service cannot be represented without adding free-text exceptions everywhere.

Separate pages, assets and operational data

Words on pages are only one part of the move. Images need ownership, alt text and usage decisions. PDFs may contain inaccessible or obsolete information that should become HTML. Forms need routing, retention and acknowledgement rules. Directories, locations, prices and opening times may be supplied by another system and should not be copied into static text.

Classify these elements separately in the migration plan. Confirm whether each asset will be reused, replaced or removed, and check its licence where necessary. For operational data, identify the authoritative source and how updates will reach the new website. A one-off import can make the site accurate on launch day while leaving it without a dependable way to stay accurate.

Assign ownership and approval early

A migration schedule based only on technical batches can hide the real constraint: people need to make content decisions alongside their normal work. Name an accountable owner for each section or content type, and be clear about which decisions editors can make without escalation.

Plan review rounds around meaningful batches rather than sending hundreds of pages at once. Provide reviewers with the source, proposed destination, decision required and deadline. Record approvals in one place. Approval by silence is risky when the content covers public guidance, contracts, safeguarding, prices or regulated services.

Ownership must continue after launch. Add review dates and escalation routes to the new operating model. Content without a future owner will begin ageing as soon as the migration team closes.

Protect URLs and search journeys

Changing the navigation does not remove the value of existing URLs. People may arrive through search engines, bookmarks, emails, partner websites, QR codes or printed documents. Build a URL map that gives every important old address an intentional outcome.

Use permanent redirects when there is a clear equivalent page. Do not send every retired address to the homepage; that removes context and can be confusing for users. Where content has genuinely ended, a clear not-found response with useful onward routes may be more honest.

Record current search performance and popular internal search terms before launch. This helps the team protect valuable landing pages, preserve language users recognise and detect a migration problem quickly. Metadata, canonical URLs, headings and indexation rules also need deliberate mapping rather than being left to a default importer.

Include accessibility, privacy and legal checks

Migration is a useful point to remove barriers that have accumulated over time. Check heading structure, link wording, table markup, image alternatives, captions, document formats and the reading order of complex content. Automated checks can find many repeatable defects, but representative pages still need manual review with keyboards, zoom and assistive technology.

Review personal data and tracking at the same time. Old forms, embedded services and downloadable documents can expose information or retain it longer than intended. Confirm the purpose, lawful handling, access controls and retention route for each data-collecting feature before recreating it.

Legal and policy content needs named approval and version evidence. A visually unchanged privacy notice can still be wrong if the new platform introduces different analytics, hosting, suppliers or form processing.

Rehearse the migration with representative content

Run a trial migration early enough for its findings to change the design. The sample should include simple pages, long guidance, tables, documents, media-heavy content, unusual layouts, redirects and records with missing or inconsistent fields.

Measure what needs manual correction after import. If editors repeatedly repair headings, links or image references, improve the transformation rather than scaling the repair task across the whole estate. Automated migration scripts should produce logs showing what moved, what changed and what failed.

Repeat the import into a clean environment once the rules are stable. A process that only works on a database already altered by developers is not a dependable launch plan.

Control changes near launch

Content continues to change while the new website is being built. Decide when the source will freeze, which urgent changes can still be made and how those changes will be reflected in both systems. A long, absolute freeze is rarely realistic, but an undocumented period of dual editing leads to missing updates.

Keep the final migration window proportionate to the estate. Separate content that can move in advance from records that must be current at launch. Confirm who can authorise a late change and how the team will reconcile it.

The rollback plan should cover content as well as code. Retain the source exports, redirect map, migration logs and approval record. If the launch is paused or reversed, the team needs to know which system contains the latest authorised version.

Validate outcomes after the import

A successful command or matching record count does not prove that the new site is correct. Validate the migration at several levels:

• every approved source item has the expected destination or retirement outcome;
• structured fields contain the right values and relationships;
• links, assets, forms, redirects and integrations work;
• representative pages render correctly across devices and assistive technologies;
• restricted and unpublished content has not become public; and
• owners can find, edit and publish their content using the agreed workflow.

Use automated comparisons for scale and targeted human checks for meaning. Sample high-risk content more heavily than routine news archives. Record defects against the migration reference so recurring causes can be fixed systematically.

Continue monitoring after launch. Watch not-found requests, failed searches, form completion, feedback and traffic to important journeys. Some issues only become visible when real users follow old links or use language the project team did not anticipate.

A content migration is successful when the new website begins with information that is useful, owned, accessible and maintainable. The import is only one mechanism inside that work. By deciding purpose, structure, ownership, destinations and evidence before the bulk move, an organisation can launch a better service instead of giving its old content estate a new surface.