Why a self-hosted Sitecore alternative for on-premise hosting starts with SitecoreAI
If your Sitecore XP or XM estate has to run in your own data center, the first question is not which CMS to pick but why SitecoreAI cannot be the answer. SitecoreAI, formerly XM Cloud, is Sitecore's forward path, and Sitecore describes it as a composable SaaS CMS. That makes it a poor fit for a hard on-premise requirement. The self-hosted options that remain are Drupal and Wagtail, both of which run on infrastructure you control. Which one fits, and when you need to move, depends on your Sitecore support dates and on how much of the estate must be migrated rather than rebuilt.
Start by confirming the constraint in writing. Ask Sitecore whether any deployment of SitecoreAI can run in your facilities, and list the controls your data center rules require, such as data location, network segmentation and administrator access. Then check the migration scope in Sitecore's XM/XP to SitecoreAI migration guide. The guide says SitecoreAI requires Headless SXA, so MVC sites must be ported to Next.js, and that xDB data, email marketing content and personalization do not migrate. Those items are the real scope of any exit, whichever CMS you choose.
Treat the support calendar as the deadline. Sitecore 10.3 mainstream support has ended and 10.4 is still supported, so the decision is whether to stay on XP for a defined period or to start a replacement now. Record the exact end-of-support dates from Sitecore's own lifecycle pages, because those dates set how long you can run both platforms in parallel. Running Sitecore and the new CMS side by side is usually the lowest-risk path, but it means paying for two hosting estates until cutover is complete. Confirm that cost and the cutover plan before you commit.
What an on-premise hosting requirement imposes on the CMS
An on-premise requirement changes who holds the data, who runs the runtime, who owns the license and who recovers the content after a failure. The five cards below cover those decisions, so you can check each one against your own data center and security policy before you choose a CMS.
Data stays in your data center
SitecoreAI is SaaS only, so the content store, media and search indexes move to infrastructure the vendor operates. With Drupal, the database runs on MariaDB, MySQL, PostgreSQL or SQLite, and Wagtail runs on Django, so you choose where every table and file lives. Check where backups, search indexes, asset storage and CDN caches sit, since each can hold copies of regulated content outside the data center. Ask your security team to map every store before you pick a hosting pattern.
You control runtime upgrades
Upgrades follow your calendar, but you also own the work they create. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, so the runtime a site needs changes with each major release. Drupal 10 reaches end of life on December 9, 2026. Wagtail supports Django 5.2.x, 6.0.x and 6.1.x, so plan the Python runtime and Django line together. Assign an owner for each runtime and match your patch calendar to the core release schedule.
Licensing permits internal hosting
Neither project has a paid edition that you must license before running it in your own network. Drupal core and contributed projects are GPL-2.0-or-later, and the GPL does not require sharing code that is only used to run a website. Wagtail is BSD-3-Clause and free for open and closed-source use. Confirm that custom modules, themes and vendor-supplied code carry licenses compatible with your internal use, and record each license in your software inventory.
You own backups and exports
Once the platform runs in your environment, backups are your responsibility. A plan for Drupal or Wagtail must cover the database, the files directory and any search index, with restore tests run into a separate environment before cutover. Confirm backup retention, who can read backup copies and where encrypted copies are held. Document the export path for content, media and user records, because a vendor support team will run that work for you only if you contract it.
Identity stays under your control
Single sign-on decides how editors reach the CMS and how their access ends. The contributed SAML Authentication module lets a Drupal site act as a SAML service provider, and its latest stable release supports Drupal 10.3 and later and Drupal 11. The OpenID Connect module authenticates users from an external provider and creates accounts on first sign-in, so decide who may create accounts and how departing editors are removed. Check module versions against your Drupal line before you commit to a design.
Which open-source platforms fit an on-premise Sitecore exit
This table compares Drupal and Wagtail as full CMS platforms you host yourself, with Strapi and Payload shown as headless pairings. Read each row against your own requirements for hosting control, support dates and marketing features, since none of the options replaces Sitecore's personalization or marketing suite one for one.
| Criterion | Drupal | Wagtail | Strapi and Payload (headless) |
|---|---|---|---|
| License | GPL-2.0-or-later, no paid edition of Drupal core | BSD-3-Clause, free for open and closed-source use | Strapi Community Edition is MIT, but ee/ code needs an enterprise license. Payload is MIT |
| Hosting control | Runs on Apache or Nginx with MariaDB, MySQL, PostgreSQL or SQLite in your data center | Django application on your servers with PostgreSQL or other supported stacks you operate | Node.js service and database on your infrastructure, with the front end built separately |
| Language runtime | PHP 8.1 or later for Drupal 10, PHP 8.3 or later for Drupal 11 | Python with Django 5.2.x, 6.0.x or 6.1.x | Node.js and TypeScript, with Next.js or another front end |
| Current support dates | Drupal 11 is current, and Drupal 10 reaches end of life on December 9, 2026 | Wagtail 7.4 LTS has security support until November 2, 2027 | Confirm the supported release line and security policy with each vendor before committing |
| Built-in content and workflow | Multi-site, multilingual content, and CMS features in Drupal CMS for content teams | StreamField blocks, multi-site, multi-language, and content moderation workflows | Content types and APIs, with editorial workflow depending on the edition and plugins |
| Personalization and marketing tools | Not included in core. Requires separate tools such as Mautic or Matomo | Not included. Requires separate analytics and campaign tools | Not included. Build or integrate tools separately |
| Commercial support | Drupal vendors and agencies, with Drupal 7 extended support providers listed by the Drupal Association | Commercial support and hosting from Torchbox, the primary sponsor | Vendor support depends on the license tier you hold |
| What it does not replace | Sitecore xDB, personalization rules, Forms and marketing automation must be rebuilt or replaced | Sitecore xDB, personalization, Forms and Path Analyzer have no direct equivalent | Page building, personalization and forms must be rebuilt in the front end and separate services |
How the 10.3 and 10.4 support dates change the timing
The Sitecore support dates set the order of decisions. Sitecore 10.3 mainstream support ended in December 2025, and 10.4 is planned to follow in December 2027, so an on-premise estate on 10.3 is already outside mainstream support. Before committing, confirm both dates against Sitecore's own lifecycle pages, because they determine how much time you have to choose among the three paths: upgrading within XP, moving to SitecoreAI, or replacing the CMS with an open-source platform. Each path has a different rebuild scope, so the date you plan around should be the one you have confirmed in writing.
The open-source target has its own clock. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026. Drupal 11 is the current major version, requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later. A Drupal build started now will therefore land on Drupal 11, and the plan must include an upgrade path to Drupal 12 and the PHP version it needs. Check the Drupal core release schedule and the PHP requirements page before fixing the target version.
If Wagtail is the target, the choice is between LTS lines. Wagtail 7.4 LTS has security support until November 2, 2027, and Wagtail 8.3 LTS is scheduled for May 4, 2027 with support until November 6, 2028. Map your cutover window against each end date, and ask whether the run period after go-live will fall inside security support. Keep Sitecore live in parallel until the new site is verified, and confirm the current dates on the Wagtail release schedule, since scheduled releases can move.
Running Sitecore and the new CMS side by side during migration
A Drupal parallel run keeps the Sitecore estate live while one site, or one language path, moves to a new Drupal host. Start with a pilot site so the team can test editorial workflows, theme builds and integrations before other sites follow. Target a supported major version from the start. Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule, so a new build should plan for Drupal 11 or a Drupal 12 upgrade path.
- Routing by site or path: Map each hostname or path prefix to its origin at the reverse proxy or load balancer. Lower DNS TTLs before cutover so rollback is a configuration change, not a redeployment.
- Content sync direction: Name one system of record per content type. Sitecore stays authoritative until each content type cuts over, and Drupal receives scheduled imports from a documented export.
- Shared sign-in: Use the SAML Authentication module or the OpenID Connect module so editors sign in once across both systems during the overlap. Confirm the identity provider supports the chosen protocol.
- URLs and redirects: Keep redirect rules and canonical paths in the proxy layer so links and search rankings carry over when traffic moves.
Before routing more traffic, confirm that the pilot site meets your accessibility, performance and tracking requirements in your own environment.
A Wagtail parallel run follows the same routing pattern but adds a Python and Django runtime to operate. Wagtail supports Django 5.2.x, 6.0.x and 6.1.x, according to its repository, so pin the Django version your team can patch on schedule. Wagtail 7.4 LTS has security support until November 2, 2027, according to the Wagtail release schedule, which gives a stable base for a multi-year overlap if the team chooses the LTS line.
- Multi-site setup: Configure Wagtail sites for each hostname during the pilot, then add language roots for localized trees. Test the proxy rules for each site before any editor uses the system.
- Headless feed: If the front end is moving to Next.js, use the Wagtail headless API to serve the new front end while Sitecore still renders the legacy pages.
- Import method: Script the import from serialized Sitecore content into page models and StreamField blocks, and rerun the script for deltas. Keep the script in version control so each run is repeatable.
- Search and workflows: Confirm the search backend for your scale, either Elasticsearch or PostgreSQL, and configure moderation workflows so editors can review content in both systems.
Ask your Wagtail implementation partner to document the import scripts and the Django upgrade plan in writing before the overlap starts.
The cutover is the point where editorial writes stop in Sitecore and the proxy sends traffic to the new CMS. A short, planned freeze protects content from being lost or published twice. Agree the freeze window with editors, content owners and anyone running scheduled campaigns, because a freeze that is announced late tends to produce last-minute edits that the final import misses.
- Freeze scope: Limit the freeze to the sites and content types that cut over in that wave. Other sites keep normal publishing on Sitecore.
- Final delta import: Run a last incremental import after the freeze begins. Compare item counts, media counts and URL lists between the two systems before routing changes.
- Scheduled publishing: Cancel or move scheduled Sitecore publishing jobs that fall inside the window, and check that no campaign goes live on the old site after the switch.
- Open form submissions: Export or drain pending form submissions before the route change, and confirm where new submissions are stored from that point.
- Rollback path: Keep Sitecore readable and the old routes ready for a defined period so the proxy can point back if smoke tests fail.
Confirm the rollback window and the people who can approve a route change in writing before the freeze date is set.
Sitecore's migration guide states that the SitecoreAI pathway does not migrate xDB data, email marketing content or personalization, so these items must be rebuilt in any destination. The same practical work applies to a Drupal or Wagtail target, because neither carries over xDB contacts, analytics history or personalization rules automatically. During the overlap, keep Sitecore XP reporting and campaigns running until each replacement is verified, so marketing does not lose visibility while the new stack is built.
- Visitor analytics: Plan a self-hosted analytics replacement such as Matomo for new traffic, and decide whether historical xDB data is archived, summarized or discarded. Get legal sign-off on that decision.
- Segmentation and campaigns: Rebuild audience segments and journeys in a self-hosted tool such as Mautic, and export consent records with their source and date.
- Personalization rules: Document each XP rule, then recreate it in front-end logic, CMS audience features or a separate decisioning service. Some XP rules will have no direct equivalent and need a product decision.
- Email content: Rebuild templates and sending configuration in the replacement email tool, and test deliverability from your own sending domain before the cutover.
Ask for an inventory of xDB data, rules and email assets from your current XP environment before estimating the rebuild work.
How to deploy Drupal or Wagtail inside your own data center
This sequence takes a Drupal or Wagtail estate from a version check to a piloted site running on your own servers or private cloud, with identity, backups, and patching in place before the full estate moves. Each step ends with a check that tells you whether to continue.
Confirm runtime and database versions
Choose the Drupal or Wagtail release first, then match it to the PHP or Python runtime and the database it supports. For Drupal, confirm the PHP requirement for the target version on the PHP requirements page, and confirm the supported web server and database (MariaDB, MySQL, PostgreSQL or SQLite) on the system requirements page. For Wagtail, check the supported Django versions in the Wagtail repository, which currently lists Django 5.2.x, 6.0.x and 6.1.x. Your platform team and DeployOpen's architects can record the decision in a version matrix. The step is done when every component has a version that appears in an official source and your security team has signed off on it.
Build the hosting stack on your servers
Provision the web tier, application runtime, database, object storage for media and a cache layer inside your data center or private cloud account. Use infrastructure as code so the environment can be rebuilt from versioned definitions, and keep secrets in your existing secrets manager. Place the database and file storage on separate network segments from the public web tier and restrict administrative access through your bastion or zero trust controls. The step is done when a staging environment serves a placeholder site over TLS, logs flow to your central logging platform, and a rebuild from code succeeds in a clean network segment.
Connect identity with SAML and OpenID Connect
For Drupal, install the contributed SAML Authentication module (samlauth) and the OpenID Connect module, then configure them against your identity provider. The samlauth release supports Drupal 10.3 and later and Drupal 11, so confirm your core version first. For Wagtail, integrate your existing SSO at the Django layer or at a reverse proxy, and confirm which group claims map to Wagtail roles. Test editor, reviewer and administrator sign-ins separately, and verify that accounts are created or deprovisioned as your policy requires. The step is done when each role signs in through the identity provider and the test accounts show the expected permissions in the CMS.
Configure backups and prove restores
Set up scheduled database dumps, file system and media backups, and configuration exports, with copies stored outside the production network. Encrypt backups and record retention periods that match your policy. Then perform a restore into an isolated environment and time the steps, recording what was missing or misconfigured. Repeat the restore test after each significant change. The step is done when a restored copy boots, the content and media match the source, and the runbook lists who runs a restore and in what order.
Schedule patch windows around release cadence
Drupal publishes bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, so build those dates into your change calendar and subscribe to the Drupal Security Team announcements. Wagtail ships a feature release every three months and publishes LTS releases with defined support windows, so align on whichever line you run. Agree in advance who approves emergency security patches and how quickly they must be tested in staging. The step is done when a recurring calendar, an approval path and a staging test checklist are documented and the first patch cycle has been rehearsed.
Pilot one site before the full estate
Choose one representative Sitecore site with a manageable content volume, a clear owner and at least one multilingual or multi-site requirement. Rebuild its templates as content types or StreamField blocks, migrate a sample of content and media, and run editorial and publishing tests with real editors. Compare page load, search behavior and access control against your requirements. Record every item that did not migrate, such as xDB data or personalization rules, and decide how each will be rebuilt. The step is done when the pilot passes your acceptance tests, the editors sign off on the workflow, and the lessons learned update the runbook used for the rest of the estate.
Evidence auditors and regulators ask for on a self-hosted CMS
A self-hosted CMS moves evidence work from a vendor's shared controls to your own records. The four items below are the ones assessors usually ask to see when a Sitecore exit or on-premise CMS is reviewed. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any attestation.
Data location and access records
Document which data center, cloud account or air-gapped network holds the CMS database, media files and backups, and who holds administrative access to each. Keep access reviews, privileged account lists and change records for the editorial, database and hosting layers separately. For a Drupal or Wagtail stack, confirm whether analytics, search indexes and email services hold copies of content or visitor data outside your network, since those copies also need to be in scope.
Documented backup and restore tests
A backup only counts as evidence once a restore has been performed and recorded. Keep the backup schedule, retention settings, encryption method and the date and result of each restore test, including the time taken to bring the site back. For Drupal, this covers the database and the files directory. For Wagtail, it covers PostgreSQL, the media store and the search index rebuild. Ask your auditor which restore evidence they expect before the first test.
Patch and upgrade logs tied to release schedules
Record each core, module and dependency update with the date applied, the vendor release it came from and the test result. Map your running versions against the published support dates for Drupal, Wagtail and the PHP or Python runtime, so a reviewer can see that no component ran past end of support without a documented decision. Keep the security advisory subscriptions and the approval for each emergency patch.
Migration record of exports and rebuilds
List every Sitecore item, template, media file and form that was exported, and mark what was rebuilt by hand, such as personalization rules, email marketing content and xDB-driven segments. Sitecore's migration guide states that the SitecoreAI pathway does not migrate xDB data, email marketing content or personalization, so these gaps must appear in the record with an owner and a decision. Include reconciliation counts from source and target and sign-off by the content owner.
What teams ask before moving off on-premise Sitecore
How much effort and cost does moving off on-premise Sitecore involve?
Cost depends mostly on the size of the estate, the number of sites and languages, and how many renderings, templates and integrations must be rebuilt. There are three main cost groups: the platform build (CMS setup, front end, hosting and environments), the migration itself (content, media, forms and redirects), and the marketing tools that Sitecore bundles and open-source CMS platforms do not. Platform costs recur through hosting, security patching and upgrades, while migration work is largely one-time. No public figure for this migration is available from our sources, so ask any provider, including DeployOpen, for a written scope and quote that separates these groups. DeployOpen works from that written scope, and the quote follows from it.
How long does an on-premise Sitecore migration take?
The timeline is set by the amount of work in scope, not by the CMS choice alone. The main drivers are the number of sites and languages, the number of templates and renderings to rebuild, how much personalization or form logic must be recreated, and how many integrations depend on Sitecore APIs. Your Sitecore support dates also set a deadline. Sitecore 10.3 mainstream support ended in December 2025, and 10.4 follows in December 2027, so plan decision points against those dates. Ask for milestones and a written timeline in the scope before work starts.
What does our internal team need to supply for the migration?
Your team usually supplies the decisions and the access, which are often the slowest parts. Typical inputs include:
- Named business owners for each site, with sign-off on content and page structure
- Access to current Sitecore environments, serialized items, media libraries and analytics exports
- Content owners to review migrated pages and approve redirects
- Security and infrastructure staff to approve hosting, identity integration and backup targets
- A decision on which personalization and marketing features will be rebuilt, replaced or dropped
Confirm these responsibilities and their owners in the written scope.
Can our own developers run the migration without an outside partner?
Yes, if your team has the skills and capacity for the platform you choose. Drupal and Wagtail both have large open-source communities and documented upgrade paths, but a Sitecore exit still needs experience with rebuilding renderings, migrating media, configuring hosting and operating a production CMS. Internal teams often handle the content and business decisions while bringing in outside help for architecture, data migration, hardening or testing. Assess your team's skills against the chosen platform before deciding. DeployOpen plans, implements, hardens and supports self-hosted platforms in your own infrastructure, typically under a fixed scope agreed in writing.
Can Sitecore content be exported, and which parts cannot?
Content items, templates and media can usually be moved, but several parts cannot. Sitecore Content Serialization writes items, roles and users to YAML files, and module files define which parts of the content tree are included. Sitecore's migration guide for the SaaS path states that xDB data, email marketing content and personalization do not migrate and must be rebuilt. Expect to rebuild renderings as new components, and confirm with Sitecore exactly what your version exports. Ask your provider to list every data set in scope and mark which ones have an export path and which must be recreated.
Should we run Sitecore and the new CMS side by side during migration?
Running both in parallel is common because it lets sites move one at a time and keeps the existing site live until the new one is verified. The cost is duplicated hosting, licensing and support for the period of overlap, so keep that window as short as the scope allows. Plan redirects, URL structure, search indexing and analytics continuity before the first cutover. Agree the cutover order and rollback steps in writing, and tie the overlap period to your Sitecore support dates.
What compliance evidence does a self-hosted CMS migration produce?
A migration produces the controls and records an auditor will later review, such as access configuration, backup and restore tests, hosting documentation and change logs. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Ask your provider which evidence is delivered as part of the written scope and which must be produced by your own teams.
What drives the cost of a self-hosted Sitecore exit
The cost of leaving Sitecore for a self-hosted open-source CMS sits in five components: a one-time build and migration, the rebuild of personalization and forms, hosting and operations that recur, upgrades and support, and any Sitecore licensing you keep while both platforms run side by side. The largest swing is usually the rebuild work, because Sitecore's migration guide states that the SitecoreAI pathway does not migrate xDB data, email marketing content or personalization, and those must be rebuilt. Ask every bidder to price these as separate line items so you can see which costs are fixed and which depend on your personalization rule count and form inventory.
Build and migration cost rises with the number of sites, languages, renderings and content types, and with how much of the Sitecore estate is serialized YAML that someone must map by hand. On the open-source side, the choice of CMS changes the effort. Drupal 10 requires PHP 8.1 or later and Drupal 11 requires PHP 8.3 or later, so a quote should state which Drupal version it targets and who will pay for the upgrade path afterward. Recurring costs include hosting, database and backup operations, security patching and the support contract, which move with traffic and the number of environments you run. Confirm which items are priced per month and which are one-time.
Parallel running is the cost most often missed. If Sitecore XP stays live while the new site is built, you keep paying the existing license or subscription, the implementation partner's maintenance, and the staff who run it. Ask for the exact months that overlap in the plan, the decommission date for each Sitecore environment, and whether the quote covers a cutover rehearsal. Request a written statement of what each party is responsible for after launch, including patching, incident response and the retainer hours that cover upgrades, so the first post-migration year is budgeted before signature.
How DeployOpen works on this
DeployOpen plans, builds and hands over a self-hosted CMS inside your own data center, cloud account or air-gapped network, so content and hosting stay under your control. We start from the hosting constraint and the Sitecore 10.3 and 10.4 dates, then fix the scope in writing before any build work begins.
How we scope
- Inventory the Sitecore sites, languages, renderings, forms and integrations that the written scope must cover.
- Record which XP features, including xDB, personalization and Marketing Automation, will be rebuilt separately rather than carried over.
- Agree the hosting target, data residency rules and the period in which the existing Sitecore estate and the new CMS run side by side.
How we build
- Install the chosen open-source CMS, such as Drupal or Wagtail, on your infrastructure with the database and web server you specify.
- Rebuild templates and renderings as content types or page models, then migrate content and media in tested batches.
- Configure SSO, backups and hardening, then test editorial workflows and the public site against the agreed acceptance criteria.
How we hand over
- Document the architecture, deployment steps, configuration and content model so your own team can operate the platform.
- Deliver runbooks for backup, restore, upgrades and the cutover from the Sitecore estate, with a record of what was not migrated.
- Prepare the systems, controls and evidence your compliance assessors will request, noting that auditors, not DeployOpen, issue any reports.
How we support
- Ongoing support, upgrades and continuous security testing are available as a retainer after the fixed-scope work ends.
- Plan core and security updates against the CMS release schedule and your own change windows, with each upgrade scoped in writing.
- Confirm with us during scoping which support level, response expectations and hosting responsibilities apply to your environment.
