Open-source alternatives to Sitecore XP

Which open-source alternatives to Sitecore fit a self-hosted XP estate

If your Sitecore XP renewal is coming up, or Sitecore has pushed you toward SitecoreAI, the first question is whether you still need a platform that Sitecore operates for you. SitecoreAI, formerly XM Cloud, is a composable SaaS CMS. Sitecore describes it as requiring Headless SXA, which means an existing MVC site has to be ported to Next.js rather than kept as is. For a self-hosted estate, the short answer is this: Drupal for multi-site estates and complex content models, Wagtail for teams that already build in Python and Django, and a decoupled front end paired with Strapi or Payload where the content team wants a headless API and the front end is a separate build. Each of these runs in your own cloud account or data center, which is the main reason teams look at them.

The reasons are specific. Sitecore's migration guide states that the SitecoreAI pathway does not migrate xDB data, email marketing content or personalization, so those assets must be rebuilt on whatever you choose. The same guide says Sitecore XP features such as Marketing Automation, EXM and Path Analyzer have no SitecoreAI equivalent, which means analytics, email and journey tooling need separate products or a rebuild. Before you compare platforms, export an inventory of your XP personalization rules, experience journeys, email campaigns and xDB-dependent reports, and mark which ones have a named replacement. Ask Sitecore in writing which XP capabilities are covered by SitecoreAI and which are not, and confirm the answer against the current Sitecore migration guide.

Treat the decision as a scope question, not a license comparison. Drupal and Wagtail both give you the editorial and multi-site model in one codebase, while headless Strapi or Payload means you will build and host the front end and the marketing integrations yourself. Strapi's Community Edition is MIT licensed, but code in its ee/ directories falls under the Enterprise Edition license unless you hold a signed agreement or a Strapi Cloud subscription, so confirm which features your requirements depend on. Your renewal or end-of-life date sets the timeline, and that date should drive how much of the personalization rebuild you can sequence rather than attempt in one cut-over.

Open-source options that replace Sitecore content and delivery

Sitecore XP customers moving off the on-premise stack have a choice between a full open-source CMS they run themselves and a headless content service that still needs a frontend. The five options below differ in licensing, editing model and how much of the Sitecore XP delivery stack they replace, so the license terms and the hosting model should be checked before any platform is chosen.

Drupal for multi-site estates

Drupal is a PHP content management framework licensed under GPL version 2 or later, and its contributed projects on Drupal.org carry the same license. Teams with many sites, complex content models and strict workflow needs often find it closest to the scope of Sitecore XP. The GPL does not require you to share code that is only used to run your own website, which matters for internal customizations. The trade-off is that Drupal is a full application you must patch, host and staff, and the migration of Sitecore renderings and personalization rules is largely a rebuild.

Wagtail on Django

Wagtail is a Django-based CMS released under the BSD-3-Clause license. It supports multi-site and multi-language content and exposes a headless content API, so it can serve a traditional Django frontend or a separate JavaScript frontend. It fits teams that already run Python services and want the editorial model in the same codebase. Confirm that your Sitecore marketing workflows can be covered by your own Django code, and note that commercial support is offered by Torchbox, the primary sponsor, rather than the project itself.

Strapi with Enterprise license checks

Strapi is an open-core headless CMS. Its Community Edition is MIT licensed, but code in the ee/ directories falls under the Strapi Enterprise Edition license unless you hold a signed agreement or a Strapi Cloud subscription. Before you build on Strapi, list every feature you need and check whether it lives in ee/, because a feature you assumed was free may require a commercial agreement. Strapi pairs well with a separate Next.js or other JavaScript frontend that replaces the MVC renderings you must port.

Payload inside Next.js

Payload is an MIT-licensed CMS that installs directly into a Next.js /app folder, so the content admin and the frontend share one TypeScript codebase. It supports self-hosted MongoDB and PostgreSQL databases. This model suits teams that plan to follow Sitecore's own direction toward Next.js for rendering, but it means your developers must own both the CMS configuration and the frontend. Plan for the rebuild of personalization and experiment logic, since Sitecore's migration guide says that content and personalization do not move to SitecoreAI automatically.

Directus and its competing-use restriction

Directus gives you a database-first headless layer over an existing SQL database and a data studio for editors. It is not under an OSI open source license. It uses the Monospace Sustainable Core License (MSCL-1.0-GPL), which allows internal use, bars competing use, and converts each release to GPL-3.0 four years after release. Have counsel confirm that your planned use, including any service you sell to customers, falls under the internal-use allowance before you adopt it. Treat it as a source-available option, not a standard open-source one, in procurement documents.

Mapping Sitecore XP capabilities to open-source tools

This table maps each major Sitecore XP capability to an open-source option you can run yourself, and flags the features SitecoreAI does not carry over. Read the last column first if a feature is business critical, because marketing automation, EXM and Path Analyzer need separate tools in every case. Confirm each choice against your own data volumes, team skills and compliance scope before you commit.

Capability	Open-source option	What to confirm or plan for
Content management and editing	Drupal, Wagtail or a headless CMS such as Strapi or Payload, depending on how much editorial structure you need	Map your Sitecore templates and renderings to content types, then confirm which editing experience your authors need
Multi-site and multi-language	Drupal multisite and multilingual modules, or Wagtail's built-in multi-site and multi-language support	Confirm locale fallback rules and how each site's content is governed before you pick a platform
Digital asset handling	Drupal media library or Wagtail images and documents, with object storage in your own cloud account	Plan asset export from Sitecore Media Library, including metadata and URL redirects for existing links
Personalization	Rules and segments built in your front end or a dedicated personalization service you host	Personalization does not migrate from XP. Rebuild audiences and rules from scratch and validate them with your marketing team
Email marketing (EXM)	A self-hosted or licensed marketing automation or email platform, kept separate from the CMS	EXM has no SitecoreAI equivalent. Confirm the email tool, sending domain and consent records before migration
Marketing automation	A separate marketing automation platform integrated through APIs and webhooks	No SitecoreAI equivalent exists per Sitecore's migration guide. Confirm integration scope and data flows
Analytics and path analysis	Open-source web analytics such as Matomo or a similar tool, paired with your data warehouse	Path Analyzer has no SitecoreAI equivalent. Confirm event schemas and retention before you switch
xDB interaction and contact data	Your own data store (for example PostgreSQL) fed by event tracking, with access controls you define	xDB data does not migrate through the SitecoreAI pathway. Decide what to retain, export or discard, and confirm retention obligations

Rebuilding personalization that does not migrate

The SitecoreAI pathway does not migrate xDB data, email marketing content or personalization, according to Sitecore's XM/XP to SitecoreAI migration guide. That means every personalization rule, audience segment, campaign and email journey you depend on must be rebuilt in your new stack. Start with a written inventory before choosing any tool. Export the list of rules, segments, goals and campaigns from your XP instances, record the business purpose of each one, the pages or components it touches, the data fields it reads, and the last date someone measured its effect. Many rules will turn out to be unused or duplicated, and retiring them is cheaper than rebuilding them.

Once the inventory exists, sort each item by where its logic should live. Presentation rules that depend only on request context, such as locale, device or a campaign parameter, usually belong in the front end of your Next.js, Nuxt or Drupal templates. Audience logic that combines behavioral and profile data across channels generally needs a customer data platform or a segmentation service that your team operates. Tests of page variants or offers belong in an experimentation tool with its own statistics. Email journeys need a sending platform, and Sitecore XP features such as Marketing Automation, EXM and Path Analyzer have no SitecoreAI equivalent, so confirm each replacement against your actual usage. Consent and data retention are the questions to settle with legal before you rebuild anything. Confirm the lawful basis and consent state for each data source, how long behavioral data may be kept, how opt-outs propagate to every tool, and where profile data will be hosted. Your own privacy counsel should sign off on these answers, since no platform can answer them for you.

How the multi-year cost compares with Sitecore XP

This table sets Sitecore XP or SitecoreAI cost components beside the components you would carry with self-hosted open-source platforms. Read it as a list of what to price, not a price comparison: the license line is zero for open source, but hosting, the platform team, porting and replacement marketing tools carry real cost. Request quotes from a written scope and confirm each vendor's license terms before comparing totals.

Cost component	Sitecore XP or SitecoreAI	Self-hosted open source	One-time or recurring
Software license or subscription	Sitecore license or SaaS subscription, set by contract. Confirm the terms, term length and any usage tiers with Sitecore.	No license fee for MIT, BSD or GPL core code. Confirm the license of every extension, plugin and enterprise module you plan to use.	Recurring on the Sitecore side; none on the core open-source side
Hosting and storage	Included in SaaS for SitecoreAI; XP hosting is contracted separately. Confirm what storage and bandwidth limits apply.	Your cloud accounts or data center. Driven by traffic, content volume, asset storage and environment count.	Recurring
Backups and disaster recovery	Handled by the vendor under the contract. Ask what is covered, how restores are tested and what you can export.	Your responsibility: database, asset and configuration backups, restore tests and recovery runbooks.	Setup is one-time; running backups and restore tests are recurring
Platform team	Smaller internal team for SaaS configuration, though Next.js front-end skills are still needed.	Engineers for CMS, front end, database, infrastructure and security. Sized by number of sites, locales and release cadence.	Recurring, usually the largest ongoing line
Porting MVC renderings to Next.js	Required for SitecoreAI because Headless SXA is needed. Scope depends on the number of renderings and custom pipelines.	Needed for any headless target. Cost follows component count and how much custom logic the renderings contain.	One-time
Rebuilding personalization and analytics	xDB data, personalization and email marketing content do not migrate on the SitecoreAI path and must be rebuilt.	Replacement tools for personalization, email and path analysis are separate products. Each adds licensing or hosting and integration work.	One-time build, then recurring for any tool you license or host
Content migration and assets	Export and mapping effort in the Sitecore content model, plus a review of templates and workflows.	Schema mapping, asset transfer and link repair in the new CMS. Volume and content quality drive effort.	One-time
Implementation partner and quotes	Vendor services or partner fees, set in the statement of work. Ask for the scope, deliverables and timeline in writing.	Fixed-scope work from an implementation partner such as DeployOpen, priced from a written scope. DeployOpen does not publish prices.	One-time for build; optional retainers for ongoing support
Upgrades and ongoing support	Included in the subscription for SaaS. Ask what is included in support tiers.	Your team or a retainer covers CMS, dependency and security patches, plus testing of each upgrade.	Recurring

What you give up and the usual workarounds

Moving off Sitecore XP means losing several built-in capabilities at once, not just a license. Each gap below has a usual workaround, but each workaround adds a component, a contract or a rebuild that someone must own.

Marketing automation and EXM

Sitecore XP features such as Marketing Automation and EXM have no SitecoreAI equivalent, so campaign journeys and email sends stop with the platform. The usual workaround is a separate email service or marketing automation tool, connected to the new CMS through forms, webhooks or an API. Check consent records, unsubscribe handling and suppression lists before cutover, because these usually live in the old platform. Confirm with the vendor whether the sending tool can take over existing contact lists.

Personalization and xDB history

The SitecoreAI pathway does not migrate xDB data, so visitor profiles, interaction history and personalization rules must be rebuilt. The usual workaround is a customer data platform or analytics store that receives events from the new site and holds profile history under your own retention policy. Decide early which segments justify rebuilding and which can be dropped, because rebuilt rules need test data and editorial sign-off. Ask your privacy team whether historical profile data may be moved at all.

Sitecore ecosystem and vendor support

Sitecore's modules, partner accelerators, certifications and support contracts will not carry over to an open-source stack. The usual workaround is a support retainer with an implementation partner, or an internal platform team that owns upgrades, security patches and plugin maintenance. Ask who will answer a production incident at night and what response they commit to in writing. Budget for the retainer as a recurring cost, separate from the one-time migration.

Editor familiarity and workflow

Content editors know Sitecore's content tree, workflows and presentation tools, and that knowledge does not transfer to a headless editing interface. The usual workaround is a rebuilt editorial workflow with role-based approvals, preview and publishing rules, and a short training program before cutover. Plan a parallel period where editors can compare old and new pages. Measure how many editing tasks still need a developer, because each one is a hidden cost after launch.

Enterprise-only features in open-core tools

Several headless options are open core, so some capabilities sit behind a commercial license. Strapi's Community Edition is MIT, but code in its ee/ directories falls under the Enterprise Edition license unless you hold a signed agreement or a Strapi Cloud subscription. Check every feature you need against the license before choosing the platform, including SSO, audit logs and granular permissions. Where a needed feature is Enterprise-only, factor the license fee into the comparison.

How a move off Sitecore XP usually runs

The sequence moves sites, content, assets and marketing logic out of Sitecore XP in controlled stages, so each stage has a clear output before the next one starts. Scope, the number of sites and the depth of personalization set how long each stage takes and how much work sits in each one.

Inventory sites, renderings and integrations
Start by listing every site, site collection, rendering, component, pipeline customization, form, and external integration that Sitecore XP touches, including CRM, search, analytics and identity connections. Assign each item an owner and mark whether it is a content-facing feature, a marketing feature, or a platform dependency. The output is a signed inventory that the business and engineering leads both accept, because every later decision depends on it. Ask your partner to confirm which Sitecore XP modules are in use, since Marketing Automation, EXM and Path Analyzer have no SitecoreAI equivalent and will need separate tools or a rebuild.
Audit marketing assets and personalization rules
Catalog the xDB data, email marketing content, personalization rules, experience variations and goals in use. Sitecore's migration guide states that the SitecoreAI pathway does not migrate xDB data, email marketing content or personalization, so these must be rebuilt or replaced in the target stack. Record which rules are live, which drive revenue, and which can be retired. The output is a rebuild list with an owner and a decision (rebuild, replace with a separate tool, or retire) for each item.
Export content and assets
Export items, media library content, languages and workflow states from the Sitecore XP content tree into a format your target platform can import, such as JSON or CSV, and download the binary media files alongside them. Confirm with your partner exactly what the export covers in your environment, including versions, unpublished items, archived content and permissions, because default tooling often omits some of these. The output is a complete export set with a checksum or record count per site, stored in a location your team controls.
Map schema and migrate content into the target
Map each Sitecore template, field, and language version to a content type in the target CMS, such as Drupal content types, Wagtail page models, or Strapi and Payload collections. Decide where shared fields, media references and multi-language content will live, and write transformation scripts that run against the export. Load a sample into a staging instance and check field types, references and locale fallbacks by hand. The output is a repeatable import job and a mapping document that the content team signs off.
Build and validate a pilot site
Choose one representative site with moderate traffic, a typical mix of pages and at least one personalized or form-driven flow. Rebuild its renderings as components in the target framework, port its templates, connect search, forms and analytics, and run it in a non-production environment. Compare rendered pages, metadata, redirects and accessibility checks with the live site. The output is a pilot that the business owner accepts against written acceptance criteria, which then become the template for the remaining sites.
Port renderings and rebuild personalization across remaining sites
Apply the pilot pattern to the rest of the estate in waves, grouping sites that share templates and components. Rebuild personalization using the rule list from the audit, and where a marketing feature has no equivalent in the target, connect a separate tool and document the data flow between them. Track each site against its acceptance criteria. The output is a set of migrated sites with a known list of open defects and a documented personalization map.
Run parallel and cut over
Run the old and new sites side by side for a period agreed in the plan, comparing traffic, errors, search rankings signals, conversion events and form submissions. Update DNS, redirects and integrations in a planned window with a rollback procedure written before the window opens. Keep Sitecore XP read-only once cutover is confirmed. The output is a cutover record showing each site's status, the rollback path tested, and sign-off from the business owner.
Decommission Sitecore and retain an archive
After the agreed stabilization period, shut down the Sitecore XP environments in line with your contractual and retention obligations. Keep a read-only archive of content, databases, logs and configuration, stored where your records policy requires, and document who can access it and for how long. Confirm with your compliance and legal teams which records must be kept, since DeployOpen prepares evidence for assessments but does not decide retention policy. The output is a decommissioning record and an archive index.

Which option fits your situation

When a regulator, contract or internal policy requires content and personal data to stay in a specific country, data center or your own network, the SitecoreAI path is a poor fit because it is a composable SaaS CMS. The best-fit option here is usually Drupal or Wagtail, since both run on infrastructure you choose and have no hosted content store that you must trust a vendor to keep in place. Wagtail is the stronger choice for a Python team with a modest number of sites, while Drupal fits estates that need deeper workflow and access control.

Hosting control: Both platforms run in your cloud accounts, data centers or air-gapped networks, so you decide where backups and logs sit.
Licensing: Drupal is GPL version 2 or later, and Wagtail is BSD-3-Clause, so the code stays available to you regardless of vendor decisions.
Migration scope: xDB data and personalization do not migrate through the SitecoreAI pathway, so plan a separate export and rebuild for that data.
Audit evidence: Ask your auditor which logs, access records and backups they will require, and confirm that your chosen platform and hosting setup can produce them.

Before you commit, confirm with your compliance lead which data categories must remain in region and whether any third-party tools in your marketing stack send data outside it.

When the renewal or license increase is the main pressure, the question is which costs move from the vendor to your budget. Open-source options remove the license fee but add hosting, operations, upgrades and a support decision. Wagtail and Payload have the lowest license exposure for smaller teams, since Wagtail is BSD-3-Clause and Payload is MIT-licensed, and their code is free to run on infrastructure you already pay for.

One-time costs: Porting MVC renderings to a new front end, rebuilding personalization and migrating content are project work you pay for once.
Recurring costs: Hosting, database operations, security patching and upgrades continue for as long as you run the platform.
Support choice: Wagtail has commercial support from its primary sponsor Torchbox, while Payload and Strapi offer paid options you can compare against an in-house team.
Strapi caution: Code in the ee/ directories is under the Strapi Enterprise Edition license, so confirm which features your plan needs before you assume the Community Edition covers them.

Ask any implementation partner for a quote that separates one-time migration work from recurring hosting and support, and confirm which licenses, if any, apply to each component.

Your engineering skills shape how quickly a team can own the platform after launch. A Python team usually finds Wagtail the most natural fit, because it is built on Django and extends standard Django models, views and templates. A .NET team migrating from Sitecore should expect a language change, since none of the options listed here run on .NET, so the skills gap is real and needs a plan.

Python fit: Wagtail is built on Django, so developers who already maintain Django services can extend the CMS with familiar patterns.
Node fit: Payload installs into a Next.js /app folder, which suits teams already building in TypeScript and React.
.NET gap: Porting MVC renderings means rewriting them, so budget for retraining or hiring alongside the migration.
Hiring market: Check the local availability of Django, Next.js and Drupal developers before you choose, because the platform you pick depends on the people you can keep.
Knowledge transfer: Ask for documented component libraries and runbooks so the skills do not sit with one partner.

Confirm with your engineering leads which language and framework they will maintain for the next several years, and use that answer to narrow the list before any proof of concept starts.

When front-end teams want to ship with React, Vue or Next.js and manage content through a separate API, a headless CMS is the natural fit. Payload and Strapi both expose content through APIs and suit teams that want the editing model separate from the presentation layer. Payload is MIT-licensed and runs inside a Next.js project, while Strapi is open core, so its Community Edition is MIT but its ee/ code is under a separate license.

Headless delivery: Content models are exposed through APIs, so each front end can be built and deployed on its own schedule.
Database choice: Payload supports self-hosted MongoDB and PostgreSQL, so you can align the database with your existing operations skills.
Editorial gap: Headless tools often need more custom work for previews, workflows and visual editing than a traditional CMS, so scope that work early.
Licensing check: Confirm which Strapi features sit in the Enterprise Edition before you design around them.
Component migration: MVC renderings become front-end components, so the port is a rebuild rather than a configuration change.

Ask your team to list the editorial features they depend on today, such as preview and scheduling, and confirm each one works in the candidate platform before you finalize the front-end design.

Questions teams ask before moving off Sitecore

How much effort does a move off Sitecore XP take?

The effort depends mostly on how much your XP estate has been customized, not on the size of the content alone. The main drivers are the number of MVC renderings and layouts that must be ported to Next.js if you move to SitecoreAI, the depth of personalization and marketing automation logic that has to be rebuilt, the number of sites, languages and content types, and how many integrations depend on xDB or EXM. Sitecore's migration guide states that the SitecoreAI pathway does not migrate xDB data, email marketing content or personalization, so those items add work that a like-for-like move would not. Ask any provider to break its estimate into rendering ports, content model mapping, marketing rebuilds, integrations, testing and cutover.

How long does a migration off Sitecore usually run?

No reliable duration can be given without a written scope, because it varies with the drivers above. Plan the work in phases: an inventory of renderings, content, integrations and marketing assets, a proof of concept for one representative site, the full build, parallel running, and cutover. Also check your own deadlines first. Sitecore's guidance on the SitecoreAI path and your Sitecore support or license dates set the outer boundary, and those dates should be confirmed directly with Sitecore for your contract.

Can our internal team migrate off Sitecore without outside help?

Teams with strong .NET, front-end and platform skills can do much of the work internally, but the decision depends on capacity and on experience with the target stack. The target stack (Drupal, Wagtail, or a headless CMS such as Strapi or Payload with a Next.js front end) needs its own skills in hosting, database operations, backups, upgrades and security hardening. Be realistic about the parallel workload: your team must keep the live XP estate running while rebuilding. Many organizations use a mix, keeping content and editorial ownership in-house and bringing in outside help for the platform build, integrations and hardening. DeployOpen plans, implements, customizes, integrates, hardens and documents self-hosted open-source platforms in the client's own infrastructure under a written, fixed scope.

Which Sitecore XP marketing features need separate tools?

Several XP marketing capabilities have no SitecoreAI equivalent, according to Sitecore's migration guide. Sitecore names Marketing Automation, EXM (email marketing) and Path Analyzer as examples. Each of these usually needs a replacement chosen separately, such as a dedicated email service, a marketing automation platform, or a web analytics tool that you run or host yourself. Map every feature you use today to a named replacement or a decision to drop it, and confirm the current feature list with Sitecore for your version. Open-source options exist for parts of this list, but the gap should be evaluated feature by feature rather than assumed closed.

Can xDB data be moved to the new platform?

Sitecore's migration guide states that the SitecoreAI pathway does not migrate xDB data, so you should not plan on importing interaction history or contact profiles as-is. Decide early which xDB data you need for reporting, segmentation or audit, and where it will live. Options include exporting what you are permitted to keep to a warehouse or analytics store, or accepting a cold start for personalization. Involve legal and privacy owners before exporting any personal data, and confirm with Sitecore which export tools apply to your version.

What licensing should we check in open-core CMS tools?

Check which parts of the product fall under which license before you build on it. Strapi is open core: its Community Edition is MIT, but code in its ee/ directories is under the Strapi Enterprise Edition license unless you hold a signed agreement or a Strapi Cloud subscription, according to the Strapi LICENSE file. Ask whether each feature you need sits in the community code or the enterprise code. Also confirm the license of every plugin and theme. WordPress and Drupal use GPL-family licenses that apply to derivative code, and Wagtail is BSD-3-Clause. Have your legal team review the result before you commit.

How do we keep the new platform secure and compliant after launch?

Security and compliance work continues after go-live and is usually a recurring cost. Plan for patching the CMS and its dependencies, hardening the hosting environment, managing secrets and access, running regular backups with tested restores, and collecting evidence for any assessment your organization must pass. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, which come from independent auditors and certification bodies. Security testing of applications and APIs can be scoped separately, and ongoing support, upgrades and continuous testing are available as retainers.

How DeployOpen scopes and runs a Sitecore replacement

DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure. For a Sitecore replacement, we start from a written scope that separates what migrates from what must be rebuilt, then deliver the platform, its integrations and its evidence in the client's own cloud account, data center or air-gapped network.

How we scope

Inventory which Sitecore XP features in use have no SitecoreAI equivalent and need separate tools
Map MVC renderings, personalization rules and email content that must be rebuilt rather than carried over
Agree deliverables, timelines and exclusions in writing before any work begins, as engagements are fixed-scope
Confirm hosting location, data residency and identity requirements with your security and compliance leads first

How we build

Implement the chosen open-source CMS, such as Drupal, Wagtail, Strapi or Payload, in your own infrastructure
Rebuild templates, components and personalization logic against an agreed content model and editorial workflow
Run security testing on applications and APIs before launch, including access control and authentication checks
Integrate analytics, search, identity and marketing tools that replace the XP features you retire

How we hand over

Document architecture, configuration, runbooks and the content model so your own team can operate the platform
Set up backups and restore testing as part of the delivered scope, with the restore results recorded
Prepare controls and evidence for your compliance assessment, noting that independent auditors issue any reports
Walk your editors and engineers through the platform before cutover and agree the acceptance criteria in writing

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Patch and upgrade the platform on a schedule agreed in the retainer, with changes tested in a non-production environment
Ask any vendor or implementation partner to confirm support windows and which tasks fall under your retainer
Request a quote from the written scope, since DeployOpen does not publish a price list

Open-source alternatives to Sitecore