How to migrate from Sitecore or AEM to headless without losing SEO, leads or tracking

Most B2B teams on Sitecore or AEM do not decide to migrate. They are pushed by a renewal, a forced upgrade or the end of support on the version they run. Both vendors are moving customers toward their cloud products, and the support calendar for older versions is now explicit.

On the Sitecore side, the platform formerly called XM Cloud evolved into SitecoreAI, announced at Sitecore Symposium in November 2025, and existing XM Cloud customers were upgraded to it automatically. Teams still on Sitecore XP or XM face version dates and, according to a partner summary of Sitecore's own lifecycle article, production incident support and security updates in Extended Support became paid from June 1, 2026. On the Adobe side, AEM 6.5 is being replaced by AEM as a Cloud Service or AEM 6.5 LTS.

Sitecore dates are from a partner summary of Sitecore KB0641167; check your own contract and support portal before you plan around them. If you are still weighing a new platform against an agent-run build, our article on enterprise headless without a DXP sets out the cost and operating model, and our comparison of agent-run headless vs Contentful, Storyblok, Sanity and DXP suites covers the vendor options. This guide assumes the decision to leave is made and focuses on what you must not lose.

A DXP site built over eight or ten years holds far more than the page tree shows: campaign landing pages nobody remembers, PDFs with backlinks, vanity URLs printed on trade show banners, and language versions created by different regional teams. The inventory is the single most valuable document in the project, because everything later is checked against it.

We build it from several sources at once, because no single source is complete. The CMS export misses URLs created by rules and redirects. The crawl misses orphan pages. Search Console misses pages without impressions. Together they come close.

• Every URL from a full crawl, the XML sitemaps, the CMS content export and the existing redirect rules, including the ones configured in the CDN or web server.
• Search Console clicks and impressions per URL for the last 16 months, and the queries each important page ranks for.
• Backlinks per URL from your SEO tool, so pages with external links are never left without a redirect.
• Every form, with its fields, hidden fields, destination (CRM, marketing automation, email) and the campaigns that point to it.
• Every tag in Google Tag Manager or Adobe Launch, the events it fires and the reports or audiences that depend on it.
• Language and country versions, with their hreflang annotations, and the structured data types on each template.

The safest migration keeps URLs unchanged. When that is impossible, and on Sitecore and AEM sites it often is, because paths carry content tree folders, language prefixes or .html extensions, every old URL needs a single permanent redirect to its closest equivalent. Google's documentation says 301 and 308 redirects tell it a page has moved permanently, that it recommends permanent server-side redirects whenever possible, and that the indexing pipeline uses a permanent redirect as a signal that the target should be canonical. JavaScript redirects are a last resort because rendering can fail.

Keep the map in a spreadsheet with one row per old URL, the new URL, the status code and who approved it. Test it against staging before launch with a crawler that follows redirects, and fail the release if any high-value URL returns a 404 or a chain. Then keep the redirects in place. Google's John Mueller has said Google recommends keeping a redirect for at least one year, and that three months is too short for a site move.

Do not copy the Sitecore or AEM page tree into the new system. Those trees mix presentation, personalization rules and content, and a straight copy carries years of workarounds into a clean stack. Instead, define content types from the pages that earn traffic and leads: service or solution pages, industry pages, articles, case studies, resources, events and people. Each type gets explicit fields for title, meta description, canonical, language, structured data and related links, so SEO is part of the model and not a plugin.

Forms deserve their own workstream. In our experience they are where migrations lose pipeline without anyone noticing for weeks, because the page still loads and the thank-you message still shows. The question is whether the record arrives in the CRM with the same source, campaign and consent data as before.

Rebuild each form to field-level parity: the same field names, the same hidden fields for UTM parameters, click IDs and lead source, the same consent wording and storage, and the same routing to owners. Submit test entries from every form on staging and production and trace each one into HubSpot, Salesforce or Marketo before you call the form done.

Parity means the new site reports the same events with the same names, so year-over-year comparisons and conversion goals keep working on the first day. Write the parity list from the inventory and check it on staging, not after launch.

• GA4 or Adobe Analytics: the same measurement ID, event names and parameters, conversions and key events, with internal and test traffic filtered.
• Tag manager: the same container or a documented successor, consent mode behaviour unchanged, and every ad platform pixel and offline conversion import still fed.
• Hreflang: Google requires that each language version lists itself and all other versions, with fully qualified URLs, and supports an x-default fallback. Rebuild the annotations from the content model so they cannot drift per region.
• Structured data: the same schema types per template (Organization, Article, Product or Service, FAQ, BreadcrumbList), validated before launch.
• Canonicals, robots directives and XML sitemaps generated from the new URLs, with no staging noindex left behind.

Our technical SEO checklist for B2B websites in the AI search era lists the checks we run on every template, including crawl access for AI search systems, which many older DXP setups block by accident.

A big-bang launch on a Friday is how migrations fail. We cut over in stages so each step can be measured and, if needed, rolled back.

1. Freeze content changes on the old platform two weeks before launch, and log any emergency edits so they are repeated on the new site.
2. Run the full parity checks on staging: redirect map, forms to CRM, tags and events, hreflang, structured data, Core Web Vitals.
3. Record a baseline the day before cutover: indexed pages, clicks and impressions by page group, form submissions by form, and CRM records by source.
4. Launch one section or one market first where the architecture allows it, such as the blog or a single language, and watch it for a week.
5. Switch the remaining sections, deploy the redirect rules at the CDN or server level, and submit the new XML sitemaps in Search Console.
6. Keep the old platform available read-only until the 90-day review, so content and redirect questions can be answered from the source.

Some movement in rankings after a migration is normal while search engines process the redirects. The goal is to tell normal movement from a real problem quickly. Set thresholds before launch so the team knows when to act instead of debating each dip.

Even if you plan to leave, the renewal is leverage. A clear exit plan changes the conversation, and the answers below decide how much time you have and what the move will cost.

• Which support phase our exact version is in today, what it covers, and what extended support costs per year.
• Whether a shorter renewal term, or a term aligned with our migration date, is available.
• How we export all content, media, users and form data, in which formats, and whether export tooling costs extra.
• Who owns the redirect rules and CDN configuration, and whether they can be exported as a file.
• What happens to personalization rules, analytics integrations and connected licences such as search or DAM if we leave.
• If the vendor proposes its cloud product (SitecoreAI or AEM as a Cloud Service), whether that move is an upgrade or a new implementation, and who pays for it.

Adobe states that AEM as a Cloud Service receives new features through monthly feature activation and maintenance releases twice a month, which removes upgrade projects but means your team has to keep pace with the release calendar. Weigh that against a headless or agent-run setup you control.

Our website development services cover the full migration: inventory, content model, redirect map, forms and CRM, analytics parity and the 90-day monitoring. Talk to our team before your renewal date and we will help you build the exit plan and the questions for your vendor.