Sitecore to Next.js: the rebuild you are paying for anyway.

What transfers from Sitecore to Next.js, and what does not?

You can carry over your content items, your field values, and your page hierarchy, but you cannot carry over your renderings, your personalization rules, or your xConnect data. The fields move first. Items serialized with the CLI as .yml files give you the raw fields; your templates become content types in the target, and your media becomes assets with new URLs. Renderings do not move at all: you rebuild each one as a Next.js component, and very little of your current HTML and CSS survives (so don't budget for salvage).

Check what you will lose by default. Your xDB-based personalization needs an audit, and then you recreate, replace, or retire each rule instead of assuming it follows the content. Sitecore Forms workflows need rebuilding. Your pipelines, event handlers, and scheduled tasks move to API routes, edge functions, or webhooks. And if you use built-in Solr or Azure Search, you also redesign your index, facets, and query logic, then choose a replacement such as Algolia or Coveo.

How do you plan the URL map and redirects so your search traffic survives?

You plan the URL map by exporting every live URL from your current site and giving each one a destination you approve before you build anything. Do not guess. Crawl your live site instead of trusting your sitemap, then cross-reference your server logs, because that is how you find the pages that earn traffic and links.

Keep your URLs identical wherever you can, because an unchanged URL needs no redirect. Simple wins. Where a URL must change, you use a server-side 301 or 308, which tells Google a page has moved permanently. Avoid chained redirects, so each of your old addresses points straight at its final one. Keep your redirects for at least a year, and test them with the URL Inspection Tool or a script (a spot check is not a test).

Watch what your field export misses: canonicals, hreflang, structured data, and meta tags that your Sitecore renderings generated will not appear in it, so you inventory them by hand. Start there. The free assessment reads canonical and structured data signals on your sampled pages, which gives you a starting list before you dig through templates and renderings.

How is content moved from Sitecore: export, API or crawl?

You move content by export first, through your target's API second, and by crawl only for what neither reaches. Start on disk. Install the CLI serialization plugin, then use the pull subcommand to write your items as .yml files, driven by your Module.json files. Because the files sit on disk, you can keep them in version control and diff them between passes. That alone makes each pass easier to trust.

Then script a loader that reads those files and writes entries into your headless CMS through its API, mapping each template to a content type. Expect several passes. You should check your media, links, and rich text each time, because the export does not verify them for you. Rich text is the quiet trap: it carries internal links that you must rewrite to your new URLs.

Use a crawl when you find that your rendered pages hold content that no item field does. Compare it closely. Put what you crawl next to the exported fields, and you will see exactly which of your pages the export alone would leave incomplete.

What do your editors get on Next.js compared with Sitecore?

Your editors get structured fields and a live preview in a separate admin, where Sitecore gave them one authoring environment, and the stack you choose decides how visual it feels. That choice matters, and your editors will feel it daily. If you pick Sanity, your editors click an element in the preview and jump to the field in Sanity Studio, and its docs list live preview, click-to-edit, and drag-and-drop page building with a Next.js App Router quickstart.

You should match the stack to your site. If you run a content or marketing site, Astro fits, but you give up an editor's visual canvas, plugins, and a hosted admin, so you add a CMS of your choice. For an application, personalization, or many editors, Next.js with Sanity or Contentful fits, and you assemble search, forms, and personalization around it. Neither choice is free of assembly work.

Ask your editors to walk you through one real edit today, and you will know how much of that canvas you must keep.

How long does a Sitecore to Next.js migration take, and what drives the effort?

Expect a long window. You should expect 9 to 14 months for a mid-sized enterprise XP-to-SitecoreAI migration and more than 18 months for large multi-site estates, per Sengo's estimates. Your URLs, content types, media, integrations, and locales decide where you land on that range (and most of those are things you can count today).

Your real comparison is XM Cloud against a headless CMS, because leaving XP for XM Cloud already means a Next.js rebuild. The store comes second. The CMS is the content store you put behind the same kind of front end, while most of your effort goes into rebuilding renderings as components, reworking integrations, and migrating content in several passes, whichever store you pick. The store is the smaller decision.

Count your templates first. Sengo's rule of thumb says you can move directly to SitecoreAI with fewer than 50 templates and limited custom code. Then count your custom pipelines, event handlers, and scheduled tasks, since each needs a new home you must build. And count your locales too, because each one adds to your content passes and your redirects.

When should you not move from Sitecore to Next.js?

You should not move from Sitecore to Next.js when your current site meets your goals, your support runs long enough, and your team has no problem the rebuild would fix. Do not force it. A rebuild with no problem to solve is just a cost.

Check your version first: Sitecore 10.4 is supported to 31-Dec-2027, and 10.3 to 31-Dec-2025, while 10.5 supports Windows Server 2025, SQL Server 2025, and Solr 10. If you run 10.4, you have time to plan. An upgrade keeps existing functionality in familiar locations, but a rebuild drops your MVC renderings and your xDB-based personalization.

Stay put too when your site depends on xDB personalization you cannot replace, when your search relies on built-in Solr you do not want to redesign, or when your pages already score in good standing in the assessment. Run it. You will see whether your problems sit in the platform or in your pages. I plan and run moves like this one, from legacy and WordPress estates to these stacks, and sometimes my advice is to stay. (That is a fair answer when the evidence says so.)

Questions, answered.

Your next read.

1. 01Sitecore alternativesSupport dates, licensing and the paths off XP.
2. 02AEM alternativesWhat to run when you use a fraction of the suite.
3. 03Next.js SEO auditRendering mode, metadata, hydration cost.