Migration
How do you decide whether to upgrade, replatform or rebuild the front end of a legacy CMS?
Short answer
A legacy CMS (content management system) gets upgraded when its vendor offers an in-place path, a new front end when only the site needs a redesign, and replatformed when the vendor's next step is a migration. Drupal 10.3 and later upgrade in place to Drupal 11; Kentico Xperience 13's successor is a new product, Kentico says (Drupal.org; Kentico, October 2026).
- Five deadlines in 81 days
- 9 December 2026 to 28 February 2027Drupal 10, Umbraco 13, Kentico Xperience 13, Sitecore XP 10.0 and 10.1 (Sitecore says) and AEM 6.5 core support, in that order. Deploi arithmetic from the figures above
- Drupal 10 to Drupal 11
- In-place upgrade from Drupal 10.3.0 or laterDrupal 10 reaches end of life on 9 December 2026; Drupal 11 needs PHP 8.3.0 or laterSources: Drupal.org (Drupal core release schedule, Define explicit Drupal 10 end of life date, How to upgrade from Drupal 10 to Drupal 11)
- Kentico Xperience 13 next step
- A move to Xperience by KenticoKentico calls Xperience by Kentico a new product and ships a Migration Toolkit; Xperience 13 support ends 31 December 2026Sources: Kentico (Product Support Lifecycle); Kentico Docs (Upgrade overview)
- Sanity's front end
- None built in: you build oneSanity says headless buyers must craft their own presentation layer, which can raise initial setup costSource: Sanity (Headless CMS 101: The Only Guide You'll Ever Need)
Deploi’s call
An end-of-support date forces a version decision, not a platform decision. Upgrade in place when your vendor offers a path, and buy extended support only to cover a rebuild that is already funded. Replatform to Sanity when the vendor's own next step is a migration anyway, or when the same content has to serve more than one site, app or brand.
UpgradeUpgrade on your current CMS when
- Your CMS (content management system) vendor offers an in-place path to a supported version, so the end-of-support date costs an upgrade, not a migration. As of October 2026 that covers Drupal 10.3 or later to Drupal 11, Adobe Experience Manager (AEM) 6.5 to AEM 6.5 long-term support (LTS), and Optimizely CMS 11 to 13. Adobe's pages disagree on when AEM 6.5 LTS support ends, so get that date from Adobe in writing.
- One website is your only channel, and its front end still works for editors and visitors.
- Nobody on your team will own a JavaScript front end, import scripts and redirects after launch, because Sanity ships no front end of its own.
SanityReplatform to Sanity when
- Your vendor's own next step is already a migration (Drupal 7 to Drupal 10 or later, Kentico Xperience 13 to Xperience by Kentico), so you pay migration cost on either path.
- The same content has to feed several sites, apps or brands, which page-shaped legacy content blocks.
- Your front end is being rebuilt anyway, so the front-end line exists on both paths.
- Your developers can own the schema in code, re-runnable import scripts and the redirect map.
What forces a legacy CMS decision now?
Five vendor deadlines force a legacy CMS (content management system) decision between 9 December 2026 and 28 February 2027, a span of 81 days (Deploi arithmetic from the dates below). Each date ends regular vendor support for a version, not the software, so it forces a version decision. Umbraco and Kentico both say sites keep running (Umbraco; Kentico, October 2026).
- Drupal 10 reaches end of life on 9 December 2026 (Drupal.org; Drupal.org issue, October 2026).
- Umbraco 13 reaches end of life on 14 December 2026, when security patches stop (Umbraco; Umbraco schedule, October 2026).
- Kentico Xperience 13 reaches end of support on 31 December 2026; from 1 January 2027 Kentico stops all support, security repairs included (Kentico, October 2026).
- Sitecore says extended support for Sitecore Experience Platform (XP) 10.0 and 10.1 ends on 31 December 2026 (Sitecore, October 2026).
- Adobe Experience Manager (AEM) 6.5 on premises loses core support on 28 February 2027 (Adobe; Adobe roadmap, October 2026).
The full CMS end-of-life calendar holds the other dates. Some triggers carry no vendor date: a redesign, a second site or brand, editors working around the CMS, or a runtime losing support. Microsoft's .NET (the runtime Umbraco 13 is built on) version 8 loses support on 10 November 2026, 34 days before Umbraco 13 itself (Microsoft; Umbraco docs, October 2026).
Is your vendor's next version an upgrade or a migration?
Your vendor's next supported version decides the cost of staying on a legacy CMS (content management system), because an upgrade keeps your content where it is while a migration moves it into a new site. Four of the seven paths here are in-place upgrades. Each vendor has its own page: leaving Drupal, leaving Umbraco, leaving Kentico, leaving Adobe Experience Manager (AEM), leaving Joomla and leaving Optimizely.
| Current version | Vendor's next step | Upgrade or migration, in the vendor's words |
|---|---|---|
| Drupal 10.3 or later | Drupal 11 | Upgrade in place; PHP 8.3.0 or later |
| Drupal 7 | Drupal 10 or later | Migration into a new site; the theme is rebuilt |
| Joomla 4.4 | Joomla 5 | An upgrade, not a migration; Joomla 5 is security-only to 12 October 2027 |
| Optimizely CMS 11 | CMS 13 | Direct upgrade, mostly .NET (Microsoft's framework) work |
| Umbraco 13 | Umbraco 17 LTS (long-term support) | Umbraco lists upgrade and rebuild as separate options |
| AEM 6.5 | AEM 6.5 LTS | Upgrade, which Adobe recommends planning |
| Kentico Xperience 13 | Xperience by Kentico | Kentico's upgrade path: a Migration Toolkit into a new product |
What are your options when a CMS version reaches end of support?
You have five options when a CMS (content management system) version reaches end of support, and three of them keep the CMS. Upgrading, buying time and rebuilding only the front end keep it; swapping the CMS under your front end and replatforming both leave it.
| Option | What you do | When it wins |
|---|---|---|
| UPGRADE | Move to the vendor's next supported version | An in-place path exists and one website is the only channel |
| WAIT | Buy the vendor's extended support | A rebuild is funded and scheduled, and the vendor sells cover |
| Rebuild the front end only | Keep the CMS and build a new front end on its application programming interface (API) | The CMS has a supported version but the site needs a redesign |
| Replace the CMS only | Point the existing front end at Sanity | A PHP front end still works; Sanity has an official PHP client |
| SANITY or ELSEWHERE | Replatform the CMS and the front end | The vendor's next step is a migration, or several brands share content |
Pick ELSEWHERE, another CMS, when policy says you host the content database, because Sanity's datastore can't be self-hosted (Sanity Docs, October 2026). Headless Drupal against a new CMS weighs the front-end-only option for Drupal.
When does buying extended support make sense for a legacy CMS?
Buy extended support for a legacy CMS (content management system) only when a rebuild is funded and will launch after the date, because extended support patches the old version and gives you no newer platform (Deploi's judgment). Vendors differ on what the cover includes:
- Umbraco 13: Umbraco sells 6, 12 or 24 months of XLTS (extended long-term support), and Umbraco says XLTS for Umbraco 13 projects on Umbraco Cloud ends 14 December 2028 (Umbraco XLTS; Umbraco, October 2026).
- Adobe Experience Manager (AEM) 6.5: extended support runs to 28 February 2028, with critical fixes only (Adobe, October 2026).
- Drupal 7: drupal.org points owners to certified vendors for paid security support (Drupal.org, October 2026).
- Kentico Xperience 13: Kentico's lifecycle page lists no paid extension past 31 December 2026 (Kentico, October 2026).
Ask any vendor for the price and the end date in writing before you count on it.
When is upgrading on your current CMS the right call?
Upgrading on your current CMS (content management system) is the right call when the vendor's next version installs in place and one website is your only channel. Three tests decide it (Deploi's judgment). First, the next version must install in place, not as a new product. Second, the target must still be supported after your plan ends: Optimizely maintains CMS 13 and CMS 12 and sets no end-of-life date for any version (Optimizely FAQ; Optimizely release notes, October 2026). Third, your hosting must meet the target's requirements: Drupal 11 needs PHP 8.3.0 or later (Drupal.org, October 2026). Adobe recommends planning an upgrade to Adobe Experience Manager (AEM) 6.5 LTS (long-term support) (Adobe FAQ, October 2026).
When does replatforming to Sanity win, and when does another CMS win?
Replatforming to Sanity wins when the vendor's own next step is already a migration or the same content has to feed several sites, apps or brands. Another CMS (content management system) wins when policy requires a self-hosted content database or your team wants pages rendered without developers.
- Sanity, when the vendor's path is a migration. Drupal 7 is a rebuild on every path: drupal.org says its content moves into a new Drupal 10 or later site with a rebuilt theme (Drupal.org, October 2026). Kentico calls the move from Kentico Xperience 13 an upgrade, but its docs call Xperience by Kentico "a new product" (Kentico; Kentico docs, October 2026). You pay migration cost either way, so price Sanity beside the vendor's own next version.
- Sanity, when brands share content. One content source for several brands is the case for running several sites from one content platform.
- Another CMS, for self-hosting or pages without developers. Sanity's datastore can't be self-hosted (Sanity Docs, October 2026), and a headless CMS has no built-in front end, so "businesses must craft their own presentation layer" (Sanity, October 2026).
On either path, copying your structure as-is "opens the door to recreating your existing problems, just on a new stack" (Sanity Learn, October 2026), which is the case for remodeling content instead of lifting and shifting it.
How do you compare the cost of staying with the cost of moving?
Compare the cost of staying on a legacy CMS (content management system) with the cost of moving over the same horizon, including the next forced event. Plan lines can carry list prices (what Sanity's plans cost); the rest comes from your own quotes, so we give drivers, not totals.
| Cost driver | Staying | Moving to Sanity |
|---|---|---|
| One-time platform work | The vendor upgrade, or a migration if the next version is one | Content model, import scripts, rich text conversion, redirects |
| Front end | Existing templates | A new front end you build and host |
| License or subscription | The vendor's license or subscription | The Sanity plan |
| Extended support | A vendor quote, where one is sold | No equivalent line; Sanity removes old application programming interface (API) versions with notice |
| People | Skills your team has now | JavaScript skills for Sanity Studio |
| Next forced event | The vendor's next end-of-life date | Retirement of old Sanity API versions, with notice |
Sanity says PHP teams may need to learn JavaScript for Sanity Studio (Sanity Learn, October 2026) and retires old API versions with notice (Sanity Docs, October 2026). Building the business case turns these lines into a decision.
What should you check before you choose?
Check six facts before you choose a path for a legacy CMS (content management system), because each one can flip the answer. Sanity says the old CMS's export options decide the migration strategy, and a content API (application programming interface) avoids a content freeze at launch (Sanity Learn, October 2026).
Checks before you choose
- Pin the exact version. Record the major and minor version, because Drupal 10 needs 10.3.0 or later to upgrade in place (Drupal.org, October 2026).
- Check the runtime. Find the support date of the PHP, Java or .NET (Microsoft's application framework) release under your CMS; .NET 8 ends on 10 November 2026 (Microsoft Learn, October 2026).
- Read the vendor's upgrade path. Note whether the next version installs in place or as a new product.
- Get an extended-support quote. Ask for the price and the end date in writing.
- Find the export route. Look for a content API, then a file or database export, then web scraping when neither exists (Sanity Learn, October 2026).
- Count channels and front-end age. List every site, app and brand that uses the content, and when the front end was last rebuilt.
Once you choose Sanity, the move from any CMS to Sanity covers the migration itself, including re-runnable migration scripts that reuse your old document IDs (Sanity Learn, October 2026).
Deploi’s point of view
- Where we disagree
- The common pitch treats every end-of-life date as a reason to leave the platform. Most vendors on this list offer an in-place upgrade or sell more time, and Umbraco and Kentico both say the software keeps running after its date. The second mistake is pricing a headless CMS as a CMS swap. Sanity renders no pages, so a new front end is a full line in the estimate from day one, not an extra found halfway through.
- What we’ve seen
- We move content into deploi.ca's own Sanity datasets as packages with an import, count checks and a rollback by document ID list; the first wave of our Shopify data section was 406 documents and 159 images, in October 2026. Our release scripts for the Shopify FAQ hub run as dry runs unless told to apply, skip any document edited since the snapshot, and start from a dataset export. That is the discipline a CMS exit needs. Our view of each legacy CMS here rests on its documentation and public sources. Deploi is not a Sanity partner.
- What we'd tell you to do first
- Write down the exact version and minor you run, then read the vendor's own upgrade page before any replatforming talk. If the vendor says upgrade, price that first; it is the number every other option has to beat.
- What we refuse to promise
- We won't put hours, a timeline or a total for leaving a legacy CMS on this page, because each depends on your own site and on prices your vendors quote rather than publish. The estimate for a real project is agreed in writing before work starts.
When this answer changes
- Drupal.org moves Drupal 10's 9 December 2026 end of life or announces extended support for Drupal 10
- Kentico offers paid support for Kentico Xperience 13 past 31 December 2026
- Adobe publishes one end date for AEM 6.5 LTS on all its pages
- Optimizely sets an end-of-life date for CMS 11
- Sanity publishes migration courses for AEM, Kentico, Umbraco or other legacy CMSs beyond WordPress and Webflow
Follow-up questions
Sources
Every source opened and checked on 25 October 2026.
- Sanity Learn, Planning a re-platforming project
- Sanity, Headless CMS 101: The Only Guide You'll Ever Need
- Sanity Docs, Libraries
- Sanity Docs, Studio development
- Sanity Docs, API Versioning
- Sanity Learn, Migrating without downtime
- Drupal.org, Drupal core release schedule
- Drupal.org, Define explicit Drupal 10 end of life date
- Drupal.org, Upgrading from Drupal 6 or Drupal 7: Overview
- Drupal.org, How to upgrade from Drupal 10 to Drupal 11
- Drupal.org, Drupal 7 End of Life
- Umbraco, Umbraco 13 End-of-Life (EOL)
- Umbraco, Long-term Support (LTS) and End-of-Life (EOL)
- Umbraco, Extended Long-Term Support for Umbraco 13
- Umbraco Documentation, Requirements (CMS 13)
- Microsoft, .NET and .NET Core official support policy
- Microsoft Learn, Microsoft .NET and .NET Core lifecycle
- Kentico, Product Support Lifecycle
- Kentico, End of Support, Not End of the Story
- Kentico Docs, Upgrade overview
- Adobe, AEM 6.5 On-premise support timelines and service pack policy
- Adobe, Adobe Experience Manager releases roadmap
- Adobe, AEM 6.5 LTS Frequently Asked Questions
- Adobe, Products and technical support periods
- Joomla, Joomla 5.3.4 Security & Bugfix Release
- Optimizely, FAQs for CMS 13
- Optimizely, 2026 Optimizely CMS 12 release notes
- Sitecore, Product Support Lifecycle (KB0641167)
- Joomla, Joomla! Project Roadmap