WordPress to Next.js migration checklist

A custom interface or a shared content source can justify a headless setup. If the existing WordPress site already meets the publishing and presentation needs, the additional frontend may add maintenance without solving a useful problem.

Write down the outcome first: a different visitor journey, reusable content across products or a specific interaction requirement. Separate that goal from an assumption that a framework alone will improve traffic.

List page types, posts, media, menus, custom fields, forms and integrations. Include category/archive pages and downloads where visitors or links depend on them. Record what remains, what changes and who decides.

Download the synthetic content inventory. It uses a fictional campus with a building page, availability, contact and a brochure. It is a planning example, not a record of a client migration.

For each page section, agree the content fields and how missing values behave. An editor changing a title is different from redesigning the layout. Make those boundaries visible before content entry starts.

building.name        -> page heading
building.introduction -> introductory copy
building.brochure     -> brochure link, when provided
building.availability -> reviewed availability section

The synthetic CMS example gives these fields a concrete value. My Cambridge Research Park case study documents related Next.js/WordPress integration work; the inventory here is a separate demonstration.

Define how an editor sees a draft, who may access it and how a published change reaches the public frontend. Test a normal edit, missing media and a scheduled update where scheduling is required.

Next.js Draft Mode is one platform mechanism for previewing draft content. Authentication, content fetching and publishing behavior still need to match the chosen CMS and application.

Keep existing addresses where they still represent the same content. For addresses that change, choose a relevant destination and record the decision. A spreadsheet can reveal contradictory rules, but it cannot decide whether the new page satisfies the visitor's original need.

Use the redirect-map checker for supported structural checks and missing inventory decisions. Confirm deployed responses separately. Google's migration guidance explains the wider URL-change process.

• Search discovery Review public content, titles, canonicals, index directives, internal links and sitemap URLs.
• Editor workflow Confirm preview, publish and content ownership with someone who will maintain the site.
• Visitor tasks Check menus, downloads, mobile layouts and the enquiry form, including failure states.
• Operations Agree the deployment owner, monitoring, backup/rollback responsibilities and post-launch checks.

Use the brief builder to collect open decisions. For implementation, explore Next.js and headless WordPress development or agency development support.