Migrate from Sitecore to a composable stack
Sitecore 10.0 and 10.1 leave Extended Support at the end of 2026, and security updates in Extended Support are no longer included as standard. The vendor’s path, SitecoreAI, is a migration too. If you are moving anyway, move to Astro or Next.js, with content in Sanity or Payload and every URL kept.
Yegparian PLLC (opens in a new tab)Signs it is time to leave Sitecore
Sitecore runs some of the largest marketing sites around. These are the moments marketing and IT teams tell us it stopped fitting.
Your version is running out of support
Sitecore 10.0 and 10.1 leave Extended Support on 31 December 2026, and 10.2 a year later. Since June 2026, security updates there need a separate arrangement.
The licence covers more than you use
How many personalisation rules, xDB profiles and marketing automation plans are switched on today? If the honest answer is a few, the renewal is paying for the rest.
Every upgrade is a programme
Content management, delivery servers, xConnect, Solr and Identity Server all move together. Upgrades get budgeted like projects, so versions fall behind.
SitecoreAI is a migration too
Moving from XP or XM to the SaaS platform means headless renderings, rebuilt customisations and moved content. It is worth comparing with a composable stack before you sign.
Only a Sitecore specialist can change it
Helix solutions, renderings and .NET customisations live in a system few developers know well. Small changes queue up behind a specialist partner.
What happens to your Sitecore features
Pick what your site relies on today. Each feature becomes part of the site itself, a focused tool, or turns out not to be needed.
- Templates and fieldsSanity schemas or Payload collectionsItems move by script from the content tree, field by field, with standard values, rich text and language versions carried over.
- Renderings and placeholdersPage-builder blocksEach rendering becomes a block editors compose pages from, built once in code so every page stays on brand.
- SXAA design system in codePage designs, partial designs and rendering variants become shared layouts and components, versioned with the rest of the site.
- Experience Editor / PagesLive preview while editingEditors see the real page as they type. In Sanity they can click any text on the preview to edit it.
- Personalisation rules / xDBPersonalisation where it paysThe audit lists the rules running today. Those worth keeping move to edge logic or a dedicated personalisation tool, with consent.
- Sitecore FormsA form built into the siteValidated on the server, filtered for spam and sent to your inbox, CRM or marketing automation platform.
- Media LibraryAssets in the CMSImages and files are re-uploaded with their alt text and served through an image CDN in modern formats. An existing DAM can be connected instead.
- Language versionsBuilt-in localisationTranslations live per field or per document in Sanity or Payload, with their own URLs and hreflang.
- WorkflowDrafts, roles and reviewDrafts, version history and roles come built in. Multi-step approval is set up around how your team signs off today.
- JSS / Next.js headYour React components, reusedComponents from a headless Sitecore build carry over. Only the data layer changes, from Layout Service to CMS queries.
What changes when you leave Sitecore
Astro and Next.js decide how pages are built. Sanity and Payload are where your team edits. Sitecore still wins some rows, and the audit weighs them.
| Feature | Astro + Sanity | Next.js + Payload | Sitecore |
|---|---|---|---|
| Cost and upkeep | |||
| Open-source CMS you can self-host | Hosted by Sanity | ||
| No servers, Solr or xConnect to run | Database only | SitecoreAI only | |
| Upgrades without a re-platform | Not from XP or XM to SitecoreAI | ||
| Pages served pre-built from a CDN | Headless builds only | ||
| Content and editing | |||
| Structured, reusable content | |||
| Live preview while editing | |||
| In-context page editing | Click-to-edit preview | Live preview | |
| Multi-step approval workflow | Set up per project | Set up per project | |
| Multilingual content | |||
| Marketing | |||
| Built-in personalisation | Via a dedicated tool | Via a dedicated tool | |
| Built-in visitor profiles and analytics | XP, not XM | ||
| Marketing tools you choose and swap | Mostly within the suite | ||
Sites we've already moved
Different stacks for different jobs: a law firm on Next.js and Payload, a residential launch and our own studio on Astro and Sanity.
Yegparian PLLC
WordPressNext.js + Payload
An Austin trial litigation firm. Practice areas, matters and insights are Payload collections, and every page is pre-rendered and served from the edge.
yegparianpllc.com (opens in a new tab)25 Cuba
WordPressAstro + Sanity
A new residential address in Canary Wharf. Apartments, amenities and galleries are edited in Sanity, and the site ships as static Astro pages.
25cuba.com (opens in a new tab)Celerart
WebflowAstro + Sanity
Our own studio site. Every one of the 164 old URLs was carried over or redirected, and all content is now edited in Sanity.
celerart.com (opens in a new tab)
How we move a Sitecore site
Your Sitecore site stays live until the new one is ready. The switch is a DNS change, not a weekend of downtime.
Audit
Audit
We crawl every URL, list every template, rendering, form, personalisation rule and integration, and export your rankings. You also see which licensed features are actually in use.
Content model
Content model
Templates, base templates and SXA page designs become a clean schema in Sanity or Payload, shaped around how your team actually edits.
Content import
Content import
Items, fields, language versions and media move by script from the content tree. Rich text is converted, images re-uploaded and item-ID links rewritten to the new URLs.
Front end
Front end
We rebuild the design in Astro or Next.js: the same look, or a refresh if one is due. Existing JSS components are reused where they fit.
Redirects and launch
Redirects and launch
Every item path, alias and redirect map entry gets a permanent redirect to its new address. Metadata, sitemaps and structured data are compared before the DNS switch.
Handover
Handover
Your team gets a walkthrough of the new editor. Then the Sitecore servers can be switched off before the next renewal.
Questions about leaving Sitecore
It is a fair option, and the audit will compare both. SitecoreAI, formerly XM Cloud, keeps Sitecore’s personalisation and marketing tools under one vendor. From XP or XM it is still a migration: renderings become headless components, customisations are rebuilt and content is moved. If your team relies on those marketing tools every day, staying may be right, and we will say so.
Not if the move is planned. Every URL keeps its address or gets a permanent 301 redirect, built from item paths, aliases and your redirect maps. Titles, descriptions, structured data and sitemaps are carried over and checked before launch, and we watch Search Console for the weeks after the switch.
Mostly, yes. Your React components and styles carry over; what changes is where the data comes from. Layout Service and GraphQL calls are replaced with queries to Sanity or Payload, and placeholders become page-builder blocks.
First, which rules are actually running today, and which ones moved a number? The audit lists them. Those worth keeping are rebuilt with edge logic or a dedicated personalisation tool, and analytics runs through GA4 or the tool you choose, with consent.
Yes. Sanity and Payload give editors live preview, drafts and version history, and they only see the fields that matter for each page. Roles, permissions and sign-off steps are set up around your editorial team.
It depends on the number of templates, sites, languages and integrations. After the audit you get a fixed scope and timeline, and the Sitecore site stays live until launch day.
Keep it protected until launch: stay on the latest version you can reach, agree security coverage with Sitecore if you are in Extended Support, keep the content management server off the public internet and put a web application firewall in front of delivery. The migration removes the risk; it does not cover the months before launch.
