Services

Planning a Move to Next.js

A migration can start with a focused assessment before you commit to the rebuild. I agree the routes, templates, and publishing workflows to review, then check what the existing platform relies on and what the proposed Next.js build must preserve.

Plan a move to Next.js by identifying which routes, redirects, rendered output, metadata, CMS workflows, analytics, performance paths, and release controls must survive the cutover.

Short Answer

You receive a migration risk register and a route and redirect plan for the agreed scope, with checks for comparing the old and new sites before launch. I explain the evidence, unresolved questions, and priorities to the team doing the build. We can then agree implementation support separately, with clear ownership of the cutover checks and rollback plan.

Why It Matters

During a Next.js migration, I help commercial and delivery teams keep search visibility, editorial continuity, and release confidence intact whilst routes, templates, metadata, and publishing workflows change underneath.

Common Situations

  • Replacing a legacy SPA, CMS front end, commerce front end, or hard‑to‑maintain site where routes and content behaviour must remain commercially safe.
  • Choosing the right migration route before platform‑specific details from WordPress, Drupal, Gatsby, Shopify, Contentful, or a React SPA turn into one oversized rebuild.
  • Preserving URLs, redirects, metadata, rendered HTML, structured data, CMS workflow, analytics, performance, and release confidence during cutover.
  • At Nando’s, migration planning had to treat URL policy, release risk, technical SEO, structured data, and content operations as part of the same launch path.

Choose the source platform or migration shape that is closest to the current estate. This hub defines the launch‑risk model; the child pages handle the platform‑specific failure modes.

What I Look at First

  • Bring the current site URL, the platform you are moving from, the reason for the move, and any target launch constraints. Repository and CMS access, existing URL or redirect lists, and analytics or Search Console data help me check the plan against the current site.
  • Together we choose representative templates, commercially important URLs, and publishing journeys. I compare rendered HTML, metadata, canonicals, structured data, internal links, and crawl controls, then check CMS dependencies, release sequencing, and rollback options. Missing access or baselines are recorded as evidence gaps.
  • The Website Replatforming Risk Register helps separate source‑platform risk from general launch risk before implementation starts.
  • The Rendered HTML Migration Comparison Worksheet is useful when the risk sits in template output, crawler‑visible content, metadata, schema, links, or CMS‑driven page data rather than only in route mapping.

What Usually Changes

  • URL, route, template, content, and publishing dependencies are mapped before the platform changes.
  • Redirect, canonical, metadata, schema, sitemap, and crawl risks are identified before launch.
  • CMS, preview, build, and deployment behaviour are compared across the old and new stack.
  • Launch actions are prioritised by visibility, revenue exposure, and delivery risk.
  • The team has a migration plan that reduces avoidable search and release damage.

How This Usually Works

  1. Technical Diagnostic

    A focused review to establish what is happening, where the risk sits, and what should happen next, ending with a prioritised plan the team can take into delivery.

  2. Embedded Delivery Support

    Senior hands‑on support inside an existing team when architecture, implementation, review, and delivery decisions need to stay connected.

  3. Fractional Technical Leadership

    Ongoing senior technical direction when a team needs stronger leadership and platform ownership before a permanent hire makes sense.

This May Not Be the Right Fit If

  • You need the migration delivered without scope to flag risks or revisit decisions as implementation progresses. If your plan is already agreed and you need senior engineering support to deliver it, Embedded Technical Leadership may be a better fit.
  • The migration is expected to ignore search visibility, preview trust, content operations, or release risk until after launch. If search visibility is already the main problem, Technical SEO Recovery and Debugging is the better route.

Planning a migration?

Tell me what you're moving from, what you're moving to, and what must keep working through the change. I'll read it and suggest the next step.

Related Case Studies and Project Work

  1. Screenshot of the Nando’s website; part of John Kavanagh's selected project work.

    A Complete Migration and Replatform for Nando’s

    On Nando’s, moving from Drupal to Next.js and Vercel meant protecting routes, structured content, and search‑critical templates whilst the platform changed underneath.

    View case study
  2. Screenshot of the Virgin Atlantic & Holidays website; part of John Kavanagh's selected project work.

    A New Headless Platform for Virgin Atlantic & Holidays

    At Virgin Atlantic, migration work sat inside a high‑traffic travel estate where sequencing, release control, and front‑end stability mattered every week.

    View case study
  3. Screenshot of the IMG Licensing website; part of John Kavanagh's selected project work.

    The Long‑Term Digital Platform Evolution for IMG Licensing

    IMG Licensing's rebuild made publishing structure, page generation, and long‑term maintainability simpler rather than heavier.

    View case study