Drupal vs Strapi: which to choose

Drupal vs Strapi: when each platform is the right choice

Choose Drupal when your organization needs one system that stores content, controls editorial workflow and renders the public site. Drupal ships its own theming layer and editorial tooling, so a regulated team with a limited front-end staff can run content, permissions and presentation in one codebase. Choose Strapi when a separate front end already exists, or will be built by a product or web team that wants content delivered over APIs to several channels. Strapi serves content and leaves presentation to whoever owns the client application. Both are fair choices, and the decision turns on three questions: who builds and owns the front end, how much editorial workflow you need out of the box, and how much upgrade effort the team can carry over the life of the platform.

On the editorial side, be precise about what each platform includes by default. Strapi documentation places audit logs, review workflows and enterprise plugins on the Enterprise plan, while content history and releases are available from the Growth plan. If your compliance program depends on audit trails or approval gates, price the Enterprise plan into the comparison from the start and ask the vendor to confirm which features apply to your deployment. Drupal's workflow and revision features are part of the core product and the contributed module ecosystem, so the question becomes which modules your team must test, maintain and document. Confirm both against your own approval chain before you compare totals.

On upgrades, Drupal 10 reaches end of life on December 9, 2026, and Drupal 12.0.0 is scheduled for the week of December 7, 2026, according to the Drupal core release schedule. A team on Drupal 10 should plan its move to a supported major version now, and should check contributed modules and themes against Drupal 12 before committing. Strapi 5 runs only on Active LTS or Maintenance LTS Node.js versions, so your Node.js upgrade cadence and front-end framework upgrades form a separate, recurring workload. Ask DeployOpen and any other implementation partner to scope both upgrade tracks, and to state who owns the front end after go-live.

Which scenarios favor Drupal and which favor Strapi

This table matches common team situations to the platform that usually fits them better, and states the condition that makes each choice hold. Read each row as a conditional fit: if the stated condition is false for your team, the recommendation may reverse. Neither platform is the better choice across all scenarios.

Scenario	Better fit	Condition under which it holds
Content-heavy public site with editors who need approval workflows	Drupal	Editors need built-in content moderation, roles and a rich editorial interface, and the site also renders pages through Drupal's own theming. Strapi's audit logs and review workflows require an Enterprise plan, so confirm the cost of that plan if you choose Strapi.
Multi-channel product with its own React or mobile front ends	Strapi	Your front ends are built separately and only need content over APIs. Drupal can also serve APIs, but Strapi's API-first design matches this model with less theming overhead.
Team with strong Node.js skills and no PHP experience	Strapi	Your developers will maintain the back end, plugins and hosting in Node.js. Strapi 5 runs only on Active LTS or Maintenance LTS Node.js versions, so plan a process for tracking those versions.
Team with existing PHP and Drupal developers	Drupal	Your staff can write custom modules and themes in PHP. Retaining existing skills usually lowers the cost of ongoing maintenance and upgrades.
Organization that needs to run on an existing SQL database	Drupal	You need PostgreSQL, MySQL, MariaDB or SQLite, and your data model is established. Strapi 5 supports MySQL, MariaDB, PostgreSQL and SQLite, so confirm your database version against each vendor's requirements.
Project that depends on NoSQL storage	Drupal	You plan to use MongoDB. Strapi 5 does not support MongoDB or other NoSQL databases, while Drupal reaches MongoDB only through contributed modules, which you should verify before committing.
Long-lived site with a planned major upgrade cycle	Drupal	You can schedule Drupal 12.0.0 (scheduled for the week of December 7, 2026) and plan for Drupal 10 end of life on December 9, 2026. Budget upgrade work for module compatibility, not only core.

How Drupal and Strapi are built and deployed

Drupal is a PHP application that renders its own pages, while Strapi is a Node.js service that delivers content through APIs and leaves presentation to something else. That split shapes who builds the front end, which runtimes and databases your operations team must keep current, and how often each stack needs patching.

Monolith with its own rendering

Drupal runs as a single PHP application that stores content, manages permissions, and renders pages through its own theme layer. Editors, site builders and themers all work in one codebase. Check whether your team has PHP and Twig skills for theming, because changes to templates, modules and core usually ship through the same deployment pipeline as content structure. Confirm which theme approach your front-end developers will use before you commit.

API-only content service

Strapi is a Node.js headless CMS. It manages content types, editorial workflow and media, then serves the content over REST or GraphQL endpoints to any front end. Your web or mobile teams build and host the presentation layer separately. This means a second deployable, its own release cycle and its own hosting, so budget for front-end engineering that Drupal would otherwise cover inside one codebase.

Database support differs

Drupal 11 runs on MariaDB, MySQL, PostgreSQL and SQLite, and reaches Microsoft SQL Server and MongoDB through contributed modules. Strapi 5 supports MySQL, MariaDB, PostgreSQL and SQLite and does not support MongoDB or other NoSQL databases. If your data platform standard is MongoDB, Strapi is excluded at the database layer, and Drupal needs a contributed module whose maintenance you must assess.

Node.js LTS constraints

Strapi 5 runs only on Active LTS or Maintenance LTS Node.js versions. Your platform team must track Node.js lifecycle dates and schedule runtime upgrades on a predictable cadence, because an end-of-life Node.js version leaves Strapi unsupported regardless of Strapi's own release status. Drupal has no equivalent runtime lockstep with a JavaScript toolchain, but it does depend on a supported PHP version and database version, so confirm both against the Drupal requirements for your target release.

Patching and upgrade operations

Drupal major versions move on a published schedule, and Drupal 10 reaches end of life on December 9, 2026. Your operations work includes planned major upgrades with module compatibility checks. Strapi ships frequent minor releases, so routine patching is smaller but more frequent. Decide which cadence your change board can absorb, and ask DeployOpen or your internal team to document test environments and rollback steps for each stack before go-live.

Hosting footprint and team skills

A Drupal deployment is typically one PHP application server stack plus a relational database, with caching and search added as the site grows. A Strapi deployment is a Node.js process, a relational database and a separately hosted front end, often with a CDN in front. Compare the number of runtimes, the on-call skills and the monitoring you must operate in your own cloud account or data center. Confirm the full component list with the vendor before sizing infrastructure.

Capabilities that decide the choice in practice

This table compares the capabilities that most often decide between Drupal and Strapi: theming, editorial tooling, content modeling, identity, extensibility, API output, database support and release timing. Read each row against your front-end plan, because Drupal renders pages itself while Strapi hands content to a separate front end. Check plan-gated features and database support early, and confirm SSO details in each platform's current documentation.

Capability	Drupal	Strapi
Theming and page building	Drupal has its own theme layer and renders pages from the same platform that stores content.	Strapi serves content over APIs only, so your separate front end builds every page.
Editorial tooling	Confirm the workflow, moderation and revision options your build needs in current Drupal documentation.	Content history and releases are in Growth and Enterprise plans. Audit logs and review workflows need Enterprise.
Content modeling	Content types and fields are built inside the site and extended through modules. Confirm the permission model you need.	Content types define the API schema. Confirm field types and permission depth in current Strapi documentation.
Identity integration and SSO	Confirm SSO and directory options in the contributed modules you plan to use.	Confirm SSO support and which plan includes it in current Strapi documentation.
Extensibility	Contributed modules on Drupal.org are licensed under GPL-2.0-or-later.	Code outside ee/ directories is MIT. Code in ee/ directories carries a proprietary Enterprise license.
API output	Drupal renders pages itself, so API output depends on the modules you enable and configure.	Content is served over APIs by design, which suits decoupled front ends.
Database support	MariaDB 10.6 or later, MySQL 8.0 or later, PostgreSQL 16 or later and SQLite 3.45 or later in Drupal 11. MSSQL and MongoDB come through contributed modules.	MySQL, MariaDB, PostgreSQL and SQLite in Strapi 5. Excludes MongoDB and other NoSQL databases.
Release timing	Drupal 12.0.0 is scheduled for the week of December 7, 2026. Drupal 10 reaches end of life on December 9, 2026.	Strapi 5.58.0 was released October 14, 2026. Strapi 5 runs only on Active or Maintenance LTS Node.js versions.

What is free and what is paid on each platform

Drupal core and the contributed files hosted on Drupal.org are licensed under the GNU General Public License version 2 or later (GPL-2.0-or-later). Using, modifying and redistributing the software does not require a license fee to Drupal, and no vendor sells a paid Drupal edition that gates features. The license cost question is therefore mostly about what you pay to run the platform, not about the software itself.

Core and contributed code: Both core and contributed modules and themes on Drupal.org fall under the same GPL family terms, so a module you adopt carries the same license obligations as core.
Hosting and infrastructure: You pay your cloud, data center or air-gapped infrastructure provider for compute, storage, backups and network capacity.
Implementation and support: Build, theming, integration, hardening and upgrade work is paid to whoever performs it, whether an internal team or an outside firm under a written scope.
Third-party services: Search, email, CDN, monitoring and identity services are separate purchases with their own terms.
Database licensing: Drupal 11 runs on MariaDB, MySQL, PostgreSQL and SQLite, so your database choice determines whether any database license applies.

Confirm with your team which contributed modules you need, check each module's maintenance status on Drupal.org, and ask any implementation partner to price hosting, support and upgrades as separate line items.

Drupal 12 upgrade timing and what it means for the plan

Plan the Drupal path around three dates from the Drupal core release schedule. Drupal 11.4 was released the week of June 29, 2026, Drupal 12.0.0 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026, with no new Drupal 10 releases after that date. A team still on Drupal 10 has a short window to move to Drupal 11 before its security exposure starts to grow, and a team already on Drupal 11 will face the Drupal 12 release shortly after. Treat the Drupal 10 to 11 move and the 11 to 12 move as one program if your site will still be in service when Drupal 12 arrives.

The hard part of either move is rarely core. It is the contributed module set. Before you commit to a date, list every contributed module and custom module your site depends on, then confirm with each maintainer or in the project's issue queue whether a release exists for the target core version. Check your theme, your search and caching integrations, and any modules that touch the database layer. Also confirm that your database still matches the Drupal 11 requirements for MariaDB, MySQL, PostgreSQL or SQLite, since a database upgrade on the same change window adds risk you do not need.

If you are weighing Strapi as the content layer, the timing question is different. Strapi 5 runs only on Active LTS or Maintenance LTS Node.js versions, so your plan needs to track the Node.js lifecycle as well as Strapi releases. Strapi 5.58.0 was released on October 14, 2026, and your team should confirm which Node.js line it supports in your environment and how often you will apply Strapi minor releases. Whichever platform you choose, ask your implementation partner for a written upgrade plan that names the target versions, the module or plugin checks, the test scope and the rollback approach before the schedule is fixed.

What drives the running cost of each platform

Running costs for Drupal and Strapi come from the same places: hosting, the people who maintain the platform, the front end, and upgrades. The split between them depends on whether you build the front end in Drupal's theme layer or in a separate application that reads Strapi's API, and on which Strapi features your editors need under a paid plan.

Hosting and database infrastructure

Drupal 11 supports MariaDB 10.6 or later, MySQL 8.0 or later, PostgreSQL 16 or later and SQLite 3.45 or later, so you can often run it on a database your team already operates. Strapi 5 supports MySQL, MariaDB, PostgreSQL and SQLite, and does not support MongoDB. In both cases, the recurring cost is compute, database, storage, backups and cache layers in your own cloud account or data center. Ask the implementer to price a staging environment and a separate build pipeline for the headless front end, since a headless setup usually adds a second deployable.

Drupal and PHP skills

Drupal teams usually need developers who know PHP, Drupal's configuration management, the theme layer and contributed module maintenance. Those skills are often scarce and concentrated in a few people, which makes staffing the recurring line in many budgets. Ask whether the quote includes knowledge transfer, runbooks and a named second engineer, because a single maintainer raises the risk and the cost of turnover.

Node.js and front-end engineering

Strapi runs on Node.js, and only on the Active LTS or Maintenance LTS versions that Strapi's installation documentation lists, so you must schedule runtime moves as Node.js lines change. A headless build also needs front-end engineers for the application that consumes the API. Expect that team to be a recurring cost, not only a launch cost, and confirm who owns the Node.js runtime patching in the support scope.

Front-end build cost for headless delivery

With Drupal, theming and page rendering are part of the same codebase, which usually means one build and one release path. With Strapi, the content model is only half the job: you also build and host the front end that renders pages, handles previews and manages caching. This is largely a one-time build cost, but redesigns, new channels and accessibility fixes recur. Ask the quote to separate the content model, the front-end build and the editor preview work.

Strapi Enterprise plan fees

Strapi's documentation marks audit logs, review workflows and enterprise plugins as requiring an Enterprise plan, while content history and releases are available in the Growth and Enterprise plans. If your compliance or editorial process depends on those features, the subscription becomes a recurring line item that the open-source core does not cover. Ask the vendor which tier includes each feature you need, and get the subscription terms in writing before you compare totals.

Major upgrade effort and timing

Drupal 10 reaches end of life on December 9, 2026, and Drupal 12.0.0 is scheduled for the week of December 7, 2026, so teams on Drupal 10 face a major upgrade in the next budget cycle. Strapi 5 upgrades depend on the Strapi version and on Node.js changes, so each upgrade is a tested release with plugin and schema checks. Ask for an upgrade estimate in the quote that covers both the core move and custom module or plugin updates.

Moving from Drupal to Strapi or from Strapi to Drupal

This sequence turns a platform switch into a controlled project with a mapped content model, verified content and media, preserved URLs and a documented cutover. Each step ends with a check the team can sign off before the next one starts.

Map the content model first
Start by listing every Drupal content type, field, taxonomy, view and menu, or every Strapi collection type, single type and component, and mapping each one to its counterpart on the target platform. Drupal's entity and field model and Strapi's schema-driven content types do not match one for one, so fields such as entity references, revisions and multi-value relations need an explicit decision. The internal team owns the business meaning of each field, and the implementation partner or platform engineers confirm how it is represented. Done means a signed mapping document that lists every source field, its target field, and any field that will be dropped or merged.
Export content, media and users
Extract published and draft content, revision history where it matters, taxonomy terms, media files with their metadata, and user accounts into a neutral format the target platform can import. Media files usually need to be moved with stable paths or identifiers so embedded references still resolve after import. Passwords and session data generally cannot be migrated, so plan for password resets or single sign-on linkage instead. Done means a row-count and checksum comparison between source and export for each content type and every media file, with exceptions logged.
Rebuild templates or front ends
This is the step that most changes the cost profile. Moving from Drupal to Strapi means the team must build or select a front end that renders content from the Strapi API, along with its routing, layouts, search and caching. Moving from Strapi to Drupal means the team must build Drupal themes, Twig templates and view configurations, because Drupal provides these in the same codebase. Ask whoever builds the front end to state which parts are new code and which are configuration. Done means each page type renders from migrated content in a staging environment and has been reviewed against the design.
Preserve redirects and URL structure
Build a complete list of current URLs with their canonical targets, then map each one to its new path. Set up permanent redirects where paths change and keep high-traffic paths unchanged where possible. Confirm how the new platform handles slugs, trailing slashes and language prefixes, since these are common sources of broken links. Done means a crawl of the old site returns no unexpected 404 responses on the new staging environment, and search engine sitemaps are ready for submission at cutover.
Rebuild permissions and editorial workflow
Recreate roles, field-level access, content approval steps and publishing rules on the target platform. Drupal's roles and permissions model and Strapi's roles and permissions do not map exactly, so review each editorial task against what the target supports natively. Some workflow features, such as review workflows and audit logs in Strapi, are documented as requiring an Enterprise plan, so confirm plan requirements with the vendor before designing around them. Done means each editor role has been tested through its approval path, and the results are recorded against the original access model.
Test integrations and run parallel validation
Reconnect search, analytics, forms, identity providers, payment or third-party APIs, and scheduled jobs. Run the old and new sites side by side for a period agreed with the business, comparing content, page output and integration results. Discrepancies go back to the mapping or template steps. Done means a documented defect list with no open critical items and a written acceptance by the content owners.
Cut over and keep the old site available
Freeze content edits on the source platform for the cutover window, run a final incremental content export, switch DNS or the load balancer to the new platform, and confirm redirects and caches behave as tested. Keep the source system read-only and available for rollback until the business agrees it can be retired. Plan for a short period of post-launch monitoring for errors, broken links and missing media. Done means the new platform serves production traffic, the rollback path has been rehearsed, and the source system has a dated decommission record.

Where implementation projects usually run long

The projects that run long on either platform usually do not run long because of the software. They run long because the content model, the editorial workflow and the front-end ownership were never written down before work started. For Drupal, the build covers hosting, content types, fields, taxonomy, roles and permissions, theming in the Drupal theme layer, and the editorial tools in the content moderation and revision system. For Strapi, the build covers hosting a Node.js application, defining collection and single types in the content-type builder, configuring roles and permissions, wiring identity, and building a separate front end that consumes the API. Ask each vendor and each implementation partner to show which of these items sit inside the statement of work and which sit with your team.

Unclear content models cause the most rework. On Drupal, a field added late can ripple through templates, views and migrations. On Strapi, a relation or component changed after the front end is built breaks API consumers that were coded against the old response shape. Before you sign a fixed scope, have editors and developers sign off a content inventory that names each content type, its required fields, its relations and its localization needs. Editorial workflow is the second common gap. Drupal offers content moderation and revisions in core, while Strapi's review workflows and audit logs are Enterprise plan features under its documentation, so confirm which of your approval steps depend on a paid tier before you design around them.

Front-end ownership is the third gap, and it matters most with Strapi. Strapi delivers content over APIs only, so someone must own the presentation layer, its hosting, its accessibility testing, its caching and its release process. If that owner is undefined, the project stalls at the point where content is ready and pages are not. With Drupal, the theme is part of the same codebase, which can simplify ownership but also means theming work needs a named developer. Put the front-end owner, the identity provider integration and the upgrade responsibility into the written scope, and ask the partner to state which of those items are excluded.

Questions buyers ask before choosing Drupal or Strapi

Does Drupal or Strapi cost less to run over time?

Neither platform charges a license fee for its core code, so run cost comes from hosting, people and any paid tier. Drupal core and contributed modules are under GPL-2.0-or-later. Strapi code outside the ee/ directories is MIT licensed when you have no Strapi Cloud account, but ee/ code carries a proprietary Enterprise license. The recurring costs to model are hosting on a PHP stack with a supported database for Drupal, or Node.js hosting on an Active or Maintenance LTS version plus a separate front end for Strapi, along with upgrades, security patches and any Strapi paid plan you need. One-time costs include the build and the initial front end. When you ask for a quote, specify the hosting topology, the upgrade cadence, the Strapi features you need, and what a retainer would cover. DeployOpen agrees each engagement's scope and deliverables in writing before work starts and does not publish a price list.

What work must our team provide for a Drupal or Strapi project?

Your team provides the infrastructure, identity integration, content decisions and sign-off, whichever platform you choose. Drupal ships with its own theming and editorial tooling, so a traditional Drupal site needs fewer separate build pieces at launch. Strapi serves content only over APIs, so you also need a front end that someone designs, builds, hosts and maintains. Typical client inputs include:

A cloud account, data center or air-gapped environment that DeployOpen can deploy into
Content models, editorial roles and approval paths
Single sign-on and directory details
Front-end design and developer capacity for a headless build

Ask any implementation partner to list these inputs in the written scope so you can see which ones fall to your staff.

Can a small internal team implement Drupal or Strapi alone?

A small team can run either platform, but the skill mix differs. Drupal work centers on PHP, site building, module selection and theming, which suits teams with Drupal experience. Strapi work centers on Node.js, schema design and a separate front-end framework, so a team usually needs both back-end and front-end skills. Either way, internal teams often underestimate ongoing duties: tracking supported versions, applying patches, managing backups and testing upgrades. Start by assessing your team's skills against the platform's requirements, then decide whether to build in-house, hire a partner for the first build, or retain a partner for ongoing support. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your environment, and retainers cover continuing support and upgrades.

How does Drupal 12 timing affect a project started now?

Start on the Drupal 11 line and plan the move to Drupal 12 as a scheduled upgrade. Drupal 11.4 was released the week of June 29, 2026, and Drupal 12.0.0 is scheduled for the week of December 7, 2026, according to the Drupal core release schedule. Drupal 10 reaches end of life on December 9, 2026, with no new Drupal 10 releases after that date, so do not begin a new build on Drupal 10. Before committing, confirm that the contributed modules and any custom code you depend on support Drupal 12, and check the release schedule for changes. Ask any partner to include upgrade work and testing in the written scope and to state how upgrades will be documented and tested before production.

Which Strapi features require an Enterprise plan?

Audit logs, review workflows and enterprise plugins require the Enterprise plan, according to Strapi's documentation. Content history and releases are available in the Growth and Enterprise plans. Code in the ee/ directories is under a proprietary Enterprise license, so check with counsel if you plan to use or modify it. Before you budget, list which of these features your editorial and compliance processes need, since audit trails and approval workflows often drive the decision. Strapi's plan details can change, so confirm the current feature matrix with Strapi before signing a contract. A partner can design the content workflow and document which features the build relies on, but the plan cost itself comes from Strapi.

Can a headless Strapi build replace Drupal theming?

A headless build does not remove theming. It moves presentation out of the CMS and into a separate front end that your team designs and maintains. Drupal's theme layer, template structure and built-in editorial tooling stay inside one application, which can reduce moving parts for sites that mainly publish pages. With Strapi, you gain freedom to choose the front-end framework, but you take on responsibility for previews, page composition, accessibility and hosting for that layer. For example, an illustrative marketing site with a few templates may need one front-end application, while a portal with many user roles may need more. Ask for the front-end scope and ownership in writing before choosing the architecture.

Which databases can Drupal and Strapi run on?

Drupal 11 supports MariaDB 10.6 or later, MySQL 8.0 or later, PostgreSQL 16 or later and SQLite 3.45 or later. Microsoft SQL Server and MongoDB are available through contributed modules, so confirm the module's maturity before depending on it. Strapi 5 supports MySQL, MariaDB, PostgreSQL and SQLite, and it does not support MongoDB or other NoSQL databases. Strapi also runs only on Active LTS or Maintenance LTS Node.js versions. Check these lists against your database standards, backup tooling and DBA support model. The Drupal database server requirements page is the natural starting point for confirming Drupal support in your environment.

Official sources for licensing, releases and requirements

Start with the primary sources before you rely on any comparison, including this one. The Drupal.org licensing page explains that Drupal core and contributed files are under GPL-2.0-or-later, which matters if you plan to distribute modified code or embed Drupal in products you ship to third parties. Then open the Drupal core release schedule, because the dates there drive your upgrade plan. Confirm that Drupal 10 reaches end of life on December 9, 2026, and that Drupal 12.0.0 is scheduled for the week of December 7, 2026. Record both dates in your roadmap and ask your implementation partner to map module compatibility against the Drupal 12 timing before you commit to a build.

For the Strapi side, read the LICENSE file in the strapi/strapi repository first. It separates code outside the ee/ directories, which is MIT Expat when you run without a Strapi Cloud account, from the proprietary Enterprise license covering ee/ directories. Your legal team should decide whether any Enterprise-only feature is on your requirements list, and the Strapi introduction documentation shows which features, such as audit logs and review workflows, sit behind the Enterprise plan. Check the current plan matrix at the time of purchase, since plan contents change between releases. Also confirm your Node.js version against the Strapi installation documentation, which limits Strapi 5 to Active LTS or Maintenance LTS releases and supports only MySQL, MariaDB, PostgreSQL and SQLite.

Finally, pull the database and runtime requirements for your target Drupal version from the Drupal.org database server requirements page and compare them with your hosting standard. Drupal 11 supports MariaDB 10.6 or later, MySQL 8.0 or later, PostgreSQL 16 or later and SQLite 3.45 or later, with Microsoft SQL Server and MongoDB available only through contributed modules. Put those constraints into a written checklist for your security and platform teams, and ask DeployOpen or any partner to confirm them against your own environment, including support windows for your database engine and your patching cadence.

How DeployOpen helps teams choose and implement either platform

DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. We apply that same working method whether the team lands on Drupal, Strapi or neither, so the decision rests on the requirements rather than on who is building it.

How we scope

Map which content types, editorial roles and approval steps the team needs before choosing a platform.
Confirm who owns the front end, since Drupal renders pages while Strapi only serves content over APIs.
Put the Strapi plan tier, Drupal version path and hosting stack in the written scope before work starts.

How we build

Build the content model and editorial workflow in the chosen platform inside the client's own cloud, data center or air-gapped network.
Set up the database, such as MariaDB, MySQL, PostgreSQL or SQLite for Strapi, and confirm it matches each platform's supported list.
Test access controls, API permissions and upgrade paths, and document the results for the client's security and compliance teams.

How we hand over

Deliver runbooks for installation, backups, Node.js or PHP version changes and content model updates.
Document which features depend on a paid Strapi plan so the client's budget owner sees recurring costs early.
Hand over a written upgrade plan that names the Drupal 10 end-of-life date and the Drupal 12 timing for the client's team.

How we support

Support ongoing upgrades, patching and continuous testing as a retainer after the fixed-scope project closes.
Review each Drupal core release and Strapi release against the client's modules, plugins and custom code.
Prepare evidence for compliance assessments, though independent auditors and certification bodies issue any audit reports.

Drupal vs Strapi