Drupal vs Wagtail: when each one fits
A university, government agency or media group choosing between these two is really deciding which language its engineers will maintain for the next decade. Drupal fits teams with a large PHP-literate staff, a need for the broad contributed module catalog, and multisite governance across many departments, faculties or brands that share content types and permissions. Wagtail fits Python and Django teams that want editors to build pages from *StreamField* blocks, that plan around LTS releases, and that would rather extend the site with ordinary Python code than maintain PHP modules. Neither choice removes the need to map your content types and editorial roles before you score either platform.
Team language and upgrade cadence usually settle the question first. Drupal ships bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, but a new major version arrives roughly every three years, and Drupal 12 requires PHP 8.5 or later, so a PHP team must plan those jumps. Drupal 10 reaches end of life on December 9, 2026. Wagtail ships a feature release every three months, and each LTS release is supported for eighteen months, with Wagtail 7.4 LTS receiving security support until November 2, 2027 and Wagtail 8.3 LTS scheduled for May 4, 2027. Ask whether your team can absorb quarterly Django upgrades or will stay on LTS only, and check the Wagtail release schedule before you commit.
Identity integration, workflow depth and running cost decide the rest. Drupal's contributed SAML Authentication module (samlauth) lets the site act as a SAML service provider, and its latest stable release, 8.x-3.14, supports Drupal 10.3 and later and Drupal 11, while the OpenID Connect module includes clients for providers such as Okta and Google. Wagtail includes content workflows and moderation, but confirm its single sign-on path, group mapping and audit needs against your identity provider before you rely on it. Both licenses are free, so the recurring costs are staff time, hosting, upgrades and any paid support, including the commercial support and hosting that Torchbox offers for Wagtail. Ask each vendor or partner for a written scope covering one major upgrade, one identity integration and one editorial workflow, then test those three in a proof of concept.
Which scenario points to which platform
This table matches common team situations to the platform that usually fits better, with the supplied fact behind each call and the condition that would reverse it. Read each row as a starting point, then check the condition against your own licensing, staffing and integration needs.
| Scenario | Better fit | Why, and what would change it |
|---|---|---|
| University with many faculty sites | Drupal | Drupal's multisite and multilingual handling and GPL-2.0-or-later licensing with no paid edition suit many departmental sites under one governance model. This changes if your team has no PHP skills and no budget for an agency to maintain Drupal 11 or later. |
| Government department with strict SSO and records rules | Drupal | The contributed samlauth module lets Drupal act as a SAML service provider, and Drupal 11 requires PHP 8.3 or later with a supported database. This changes if your identity provider needs integration patterns Drupal modules do not cover, or if your team standardizes on Python services. |
| Media publisher with a headless front end | Wagtail | Wagtail includes a headless API and StreamField for structured content, and its BSD-3-Clause license is free for open and closed-source use. This changes if your front end team needs a fully decoupled architecture with mature JSON:API tooling, where Drupal's core JSON:API module may fit better. |
| Team with an existing Django codebase | Wagtail | Wagtail runs on Django 5.2.x, 6.0.x and 6.1.x, so your Python developers, deployment pipeline and hosting patterns carry over. This changes if your Django version falls outside the supported Wagtail lines or if the content team needs Drupal's larger module catalog. |
| Team that already runs PHP 8.3 or later hosting | Drupal | Drupal 11 requires PHP 8.3 or later, so existing PHP hosting may meet the platform requirement without new runtimes. This changes if the same team must also support Django services, which adds a second runtime to operate. |
| Publisher needing a long support window on a fixed schedule | Wagtail | 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. This changes if your governance requires Drupal's three-year major cycle and its Security Team advisories, which you should compare against your own upgrade capacity. |
| Large editorial site needing deep permissions and moderation | Drupal | Drupal's module ecosystem offers extensive content moderation and role-based access options. Wagtail also provides content workflows and moderation, so confirm the exact permission granularity you need in each project before deciding. |
How Drupal and Wagtail are built and deployed
Drupal and Wagtail both run on mature open-source stacks, but they ask different things of your team. Drupal is a PHP application with a database-backed module system, while Wagtail is a Django project that you extend with Python code. The cards below cover the runtime, databases, search, multisite handling and front-end options that shape patching, hosting skills and day-to-day operations.
Language and runtime
Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later, so PHP upgrades become part of each major release plan. Wagtail runs on supported Django versions, currently 5.2.x, 6.0.x and 6.1.x, so your Python team patches the framework and its dependencies on that cycle. Check whether your staff already maintain PHP or Python services, because that skill set determines who can own patching and custom code.
Request stack and web servers
Drupal runs on Apache, Nginx and other web servers in front of PHP and a relational database, which is a familiar pattern for most hosting teams. A Wagtail site is a Django application served through a Python WSGI or ASGI server behind a reverse proxy. Confirm which application server, process manager and static asset pipeline your platform team already operates, since each choice changes how you build, deploy and roll back releases.
Database support and version floors
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 only through contributed modules, so each needs its own maintenance and testing track. Wagtail's database choices are set by Django, and your database floor should be confirmed against the Wagtail release notes for the version you plan to run.
Search and indexing
Wagtail offers integrated search backed by Elasticsearch or PostgreSQL, so a smaller deployment can start without a separate search cluster. Drupal search depends on the modules you choose, and large content estates usually add a dedicated search service. Ask your team which search volume, reindex window and hosting model you expect, and test reindexing before you commit to either path.
Multisite and multilingual handling
Wagtail supports multi-site and multi-language content within one project, which suits university departments and regional government sites that share a template set. Drupal handles multisite through its own configuration and multilingual modules, and it is widely used for large multilingual estates. Decide early whether sites share one codebase and database or run as separate deployments, because that choice drives your upgrade schedule and hosting footprint.
Front-end and headless options
Wagtail includes a headless API, so you can serve content to a separate React, Vue or mobile front end while keeping Django as the editorial system. Drupal can also serve content through its core JSON:API module, but many Drupal sites still render pages through its own theme layer. Confirm which front end your team will build and host, because a decoupled setup adds a second deployment pipeline, preview workflow and caching layer to operate.
Side-by-side capabilities for content teams and developers
This table compares how Drupal and Wagtail handle content modeling, workflow, multilingual sites, headless APIs, identity integration, images and search. Read each row against your own editorial and developer needs, and treat the confirm notes as items to verify with the vendor or project documentation before you shortlist either platform.
| Capability | Drupal | Wagtail |
|---|---|---|
| Content modeling | Content types, fields and entity relationships built through the site builder or code; deep customization is typically done in PHP modules | StreamField for structured, block-based content inside Django page models; models are defined in Python |
| Workflow and moderation | Content moderation and workflow handling is part of Drupal's built-in tooling; confirm which contributed modules your editors need for approval chains | Content workflows and moderation are a built-in Wagtail feature; confirm approval steps and roles against your editorial process |
| Multilingual support | Four core multilingual modules cover interface, content and configuration translation | Multi-site and multi-language support is built in; confirm how translated page trees fit your publishing model |
| Headless API | Core JSON:API module supports decoupled front ends; confirm the field and caching setup your front end needs | Built-in headless API; confirm endpoint coverage and authentication for your front-end framework |
| SAML identity integration | Contributed samlauth module lets the site act as a SAML service provider; latest stable 8.x-3.14 supports Drupal 10.3 and later and Drupal 11 | Not covered by supplied facts; confirm SAML support and any third-party package with the Wagtail project documentation |
| OpenID Connect integration | Contributed OpenID Connect module creates accounts on first sign-in, with built-in clients for GitHub, Google, LinkedIn, Facebook and Okta | Not covered by supplied facts; confirm OIDC support and maintained packages with the Wagtail project documentation |
| Image handling and focal points | Image handling depends on core media and contributed image modules; confirm crop and focal point behavior for your media workflow | Image focal points are a built-in Wagtail feature used for cropping and renditions |
| Search | Search depends on contributed or core search modules and your chosen search backend; confirm indexing setup for your content volume | Integrated search with Elasticsearch or PostgreSQL; choose the backend that matches your hosting stack |
What the licenses and editions mean for each platform
Drupal core and contributed files hosted on Drupal.org that are derivative works of Drupal are licensed under GPL-2.0-or-later. You can run, modify and redistribute them without paying a license fee to the project. There is no paid edition of Drupal itself, so nothing in core sits behind a commercial tier. Your spend goes to hosting, implementation, maintenance and any support contract you choose to buy.
- Core and contributed code: GPL-2.0-or-later covers core and derivative contributed files on Drupal.org. Check each module's license and maintenance status on its project page before you adopt it.
- No edition ladder: Budget conversations center on build, hosting and upgrade effort, because no vendor sells a licensed Drupal tier.
- Paid help is a services market: Agencies, hosts and implementation partners sell work by scope. Ask who applies security patches and major upgrades, and who is accountable for them.
- Extended security support for legacy sites: Drupal 7 security support ended on January 5, 2025. The Drupal Association's extended support program lists HeroDevs and Tag1 Consulting as certified vendors for Drupal 7 sites that cannot migrate yet. This option applies only to legacy sites, not to a new Drupal build.
Confirm with your agency or internal team which contributed modules you need, whether each one is actively maintained for your target Drupal version, and who would cover a security gap if a module lost its maintainer.
Wagtail is licensed under BSD-3-Clause, which allows free use in open-source and closed-source work. You can keep custom code and internal extensions private, including on commercial sites. Wagtail has no edition split, so the cost question centers on hosting, build effort and whether you buy support from the project's primary sponsor or from a partner.
- Permissive terms: BSD-3-Clause permits closed-source modifications, so proprietary blocks and internal integrations do not have to be published.
- Commercial support from the sponsor: Torchbox, Wagtail's primary sponsor, offers commercial support and hosting. Confirm the scope, response terms and hosting location in writing before you rely on them.
- Support is a purchase, not a license tier: You can run Wagtail without a vendor contract, but then upgrades, patching and security response sit with your team or a partner you engage.
- Django underneath: Wagtail supports Django 5.2.x, 6.0.x and 6.1.x. Your Python and Django upgrade path runs alongside Wagtail's own release cadence, so plan both together.
- LTS windows for planning: Wagtail 7.4 LTS has security support until November 2, 2027. Wagtail 8.3 LTS is scheduled for May 4, 2027, with support until November 6, 2028.
Read the Wagtail release schedule before you pick a version, and set an upgrade window for each LTS line you adopt.
The core licenses do not settle the full picture. Each contributed module, Python package and front-end dependency carries its own terms, and vendor support is a separate commercial agreement. Both need checking before the design phase, because they affect what you can ship and who answers when something breaks.
- Contributed module licenses: Modules on Drupal.org are generally GPL-compatible, but confirm the license on each project page, since a module's terms can differ from core.
- Python and Django packages: Wagtail's dependencies and any third-party Wagtail packages come from PyPI and other sources with their own licenses. Inventory them with a software bill of materials tool and review the results.
- Sponsor and vendor contracts: Torchbox support and hosting terms, and any Drupal extended security support agreement, are negotiated apart from the open-source license. Ask for scope, term, pricing basis and exit provisions.
- Coverage limits: Ask whether a vendor covers only specific modules or versions, what response times apply, and what happens to your code and data when the agreement ends.
- Legal review: Have counsel confirm license obligations for your distribution model, especially if you deliver code or sites to customers or partners.
Request each vendor's license and support terms in writing, and confirm which contributed modules or packages your build depends on before you sign anything.
What drives the running cost of each platform
Running Drupal or Wagtail is mostly staff time, hosting, upgrades and module or package upkeep, not licence fees, since both are free software. The cards below separate one-time build costs from recurring costs and list what to ask for in any quote.
Hosting footprint and stack
Drupal runs on PHP 8.3 or later for Drupal 11 and needs a web server, one of the supported databases and, for busy sites, a cache layer. Wagtail runs on Python under Django, with Django 5.2.x, 6.0.x or 6.1.x supported. Both are inexpensive to host at small scale, so the recurring difference comes from the number of services you operate and how often you patch them. Ask the hosting partner to price each component separately, including search and caching.
Staff skills and hiring pool
Drupal sites are usually run by PHP developers who know Drupal's module and configuration model, while Wagtail sites need Python and Django engineers who can work with StreamField models and templates. Your recurring cost is the salary or contract rate of whoever owns the codebase, so check which skills your team already has before choosing. Ask any partner to name the engineers who will maintain the site after launch and how many hours they will spend each month.
Drupal major upgrades versus Wagtail LTS
Drupal plans a new major version roughly every three years, and Drupal 10 reaches end of life on December 9, 2026, so a Drupal site will need a major upgrade within a predictable window. Wagtail ships feature releases every three months, and its LTS versions carry eighteen months of support, so upgrades arrive in smaller steps. Wagtail 7.4 LTS has security support until November 2, 2027. Budget the Drupal upgrade as a planned project and the Wagtail upgrade as a recurring task.
Contributed module and package maintenance
Most Drupal sites depend on contributed modules, and each one must be checked against every core upgrade, which is often the largest share of upgrade work. Wagtail sites depend on a smaller set of Django and Wagtail packages, but third-party packages still need pinning and testing. Ask for a written module or package list with versions, the maintainer status of each, and a plan for replacing any module that no longer supports the target core version.
One-time build costs
Migration, theme build and integrations are mostly one-time costs, but they are where the largest early spend occurs. Drupal themes must be rebuilt when moving from Drupal 7, and Wagtail templates and StreamField block design are built from scratch for any new site. Single sign-on through the SAML or OpenID Connect contributed modules, search and API work are also one-time. Ask the vendor to separate build tasks from recurring operations in the quote.
Optional commercial support and retainers
Both platforms are free software, so recurring commercial spend usually means a support retainer, managed hosting or extended security support. Torchbox offers commercial support and hosting for Wagtail, and the Drupal Association lists certified Extended Security Support providers for Drupal 7 sites that cannot yet migrate. Retainers buy response times and upgrade labour, so ask for the support hours included, the response commitments in writing and what is excluded from the monthly fee.
Moving content from one platform to the other
This sequence moves content, media, users and workflows between Drupal and Wagtail while rebuilding presentation and integrations on the target side, so the cutover happens only after editors and reviewers have checked the result.
Inventory content types, workflows and integrations
Your content lead and a developer list every Drupal content type, paragraph type, taxonomy, menu, view, workflow state and contributed module in use, then mark which ones carry business rules. Include every integration that reads or writes content, such as search, forms, analytics and single sign-on. The step is done when the inventory is signed off by the content owner and the platform team, and each item is labeled as move, rebuild or retire.
Map Drupal fields and paragraphs to StreamField
A Wagtail developer maps each Drupal field and paragraph type to a Wagtail page model field or a StreamField block. Drupal paragraphs with nested fields usually become StreamField blocks, while single-value fields become typed page fields. Run the same mapping in the reverse direction if you are moving from Wagtail to Drupal, paying attention to where StreamField blocks carry structure that a Drupal field may not express. The step is done when the mapping document is reviewed by an editor who confirms no content loses meaning.
Migrate users, roles and permissions
Export accounts and role assignments from Drupal, then recreate groups and permissions in Wagtail using its page-level permissions and groups. Decide which Drupal roles map to Wagtail groups before any user data moves, and do not copy password hashes between systems unless your security team has approved the method. The step is done when a test set of accounts shows the same editing and publishing rights on both sides.
Export and import content and media
A developer writes an extraction script for content, revisions, images, documents and their metadata, then imports them into Wagtail page models and its image and document models. Content and media transfer through this step, while internal links, shortcodes and embedded media references usually need a rewriting pass. The step is done when record counts match the inventory and a sample of pages from each content type renders with correct media and links.
Rebuild themes, templates and custom modules
Front-end developers rebuild templates, styles and any custom Drupal modules as Wagtail templates, template tags, or Django apps, because theme code does not transfer from Drupal. Reproduce only the behavior the inventory marked as required, and rebuild custom logic against Wagtail's own APIs rather than porting Drupal hooks line by line. The step is done when page templates pass accessibility and visual review against approved designs and every required feature has a test.
Reconnect identity and integrations
Your identity team reconnects single sign-on for the new platform, then repoints forms, search, analytics and APIs to Wagtail endpoints. Confirm which identity protocol and module each side uses before you configure the new site, since Drupal's SAML and OpenID Connect contributed modules do not carry over automatically. The step is done when test users can sign in, and every integration in the inventory returns the expected data in a staging environment.
Run parallel review with editors
Editors and reviewers work through their normal publishing and approval tasks on the new site while the old site stays live. Compare workflow states, scheduled publishing, and moderation steps against the inventory, and log each discrepancy with an owner and a fix. The step is done when the agreed defect list is closed and the content owner signs off on the result.
Cut over and retire the source platform
Freeze content on the source site, run a final incremental content sync, switch DNS or the reverse proxy to the new platform, and keep the old site read-only for a period your rollback plan defines. Confirm redirects for changed URLs and monitor errors and search indexing after the switch. The step is done when traffic is served by the new platform, redirects are verified, and the rollback window has closed without a required reversion.
Where implementation projects usually run long
On a Drupal project, the longest stretch usually comes from content modeling and module selection, not from the core install. Each content type, field, taxonomy and view needs a decision, and most of those decisions are shaped by contributed modules that must be vetted for maintenance status and compatibility with your target core version. Identity is a separate workstream: if you plan to use the contributed SAML Authentication module (samlauth) or the OpenID Connect module, confirm which identity provider settings, attribute mappings and account-creation rules your security team requires before build starts. Hosting and environments need their own plan, including which web server, database (MariaDB, MySQL, PostgreSQL or SQLite) and PHP version you will standardize on. The main schedule risk is upgrade planning. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, so a site started on Drupal 10 now needs a dated path to a supported version. Ask your partner to show module compatibility for that path before sign-off.
On a Wagtail project, the long stretch usually sits in StreamField block design and in coordinating the Django team. StreamField blocks define what editors can build, so every block needs an agreed schema, template, accessibility review and preview behavior before content teams are trained on it. Editorial workflow and moderation settings are configured in code and admin, so the people who approve these decisions should be named early. Identity integration for Wagtail runs through Django's authentication layer, so confirm with your Django developers which SSO library and attribute mapping you will use. For lifecycle timing, 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. Plan your Django version alongside Wagtail, since Wagtail supports Django 5.2.x, 6.0.x and 6.1.x, and confirm which of those your hosting platform and dependencies can run before committing. Before signing, ask both candidates for a written list of environments, accessibility and governance review steps, and the named people who will own module or block decisions after launch.
Questions buyers ask before choosing between Drupal and Wagtail
How much does each platform cost to run?
Neither license adds a fee, so running cost comes from hosting, staff time and any support contract you buy. Drupal is licensed under GPL-2.0-or-later and there is no paid edition of Drupal itself, while Wagtail is BSD-3-Clause and free for open and closed-source use. The recurring costs are similar for both: servers or cloud accounts in your own environment, database and search services, and people to apply core and module updates. Drupal moves to a new major version roughly every three years, and Drupal 10 reaches end of life on December 9, 2026, so an older site adds migration work to its running cost. Wagtail ships a feature release every three months and offers LTS versions, so its maintenance is more frequent but smaller. Commercial support is optional on both sides. Ask every quote to split one-time build, recurring hosting, support retainer and upgrade effort for each platform, using the Drupal release schedule as the upgrade calendar.
How long does migrating a site to Drupal or Wagtail take?
No supplied figure sets a typical timeline, so the duration depends on the content model, the theme, the custom code and the integrations. For Drupal, the source version matters most: Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later, so they move into a new site through the core Migrate modules or Drush, and themes must be rebuilt. Content types with many references, multilingual translations, custom modules, and redirects for existing URLs all add work. Moving to Wagtail means mapping content into StreamField blocks and Django models, rebuilding templates, and rewriting any platform-specific logic, which is usually a full rebuild of the front end. Ask each bidder for a written scope that lists content volume, number of content types, custom modules, integrations, the cutover plan and the testing gates, then ask for the timeline that scope implies. The Drupal migration guidance describes the Drupal route in detail.
Can a team with only PHP or only Python skills run it?
Yes, but the skills differ. Drupal runs on PHP, and Drupal 11 requires PHP 8.3 or later while Drupal 12 requires PHP 8.5 or later, so a PHP team must keep the runtime on a supported version and manage module updates. Wagtail is built on Django and supports Django 5.2.x, 6.0.x and 6.1.x, so a Python team must track Django versions alongside Wagtail's feature and LTS releases. Operating either platform also means running a web server, a supported database, search, caching and deployment pipelines. Drupal 11 supports MariaDB, MySQL, PostgreSQL and SQLite, while Wagtail search can use Elasticsearch or PostgreSQL. A team with no experience in the chosen language will still need at least one person who can read, patch and test the code. Confirm the staffing plan against the version calendar before choosing, and ask the implementer to name who will own upgrades after launch.
Does Wagtail have a paid tier, or is it free?
Wagtail has no paid license tier in the supplied facts. It is BSD-3-Clause licensed and free for open and closed-source use, as stated in the Wagtail repository. The commercial options are services: Torchbox, Wagtail's primary sponsor, offers commercial support and hosting. Those are service contracts, so the price depends on the support level, response expectations and hours you need, and you should ask for the terms in writing. Drupal follows a similar pattern: Drupal and the contributed files on Drupal.org are GPL-2.0-or-later, and there is no paid edition of Drupal itself. Spending on the Drupal side goes to hosting, support, and any specialist modules or vendor services you choose. Ask each vendor to list what is licensed, what is a service, and what recurs every year, so the comparison covers the same items on both sides.
Which platform suits multilingual government sites better?
Neither platform wins on language support alone, so the answer depends on your team and governance model. Wagtail includes multi-site and multi-language support in its feature set, and its StreamField model suits structured content that editors translate block by block. Drupal's core includes multilingual support for interface, content and configuration translation. The Wagtail repository lists US and UK government organizations among its users, which is useful context but not a compliance result. Choose Drupal when your team runs PHP and you need contributed modules such as samlauth for SAML single sign-on or the OpenID Connect module for external identity providers. Choose Wagtail when your team runs Python and the site is mostly structured content served through its headless API. Ask each implementer to demonstrate the translation workflow, the approval chain and the single sign-on design using your own content samples.
What must we provide before a scoped implementation starts?
A scoped implementation starts from a written list of what you own, and that list drives the quote. Provide the current site or content inventory, including content types, volumes, languages and access rules, plus the review and approval workflow your editors use. List the integrations that must work, such as identity providers, search, forms, payment or other internal systems. Name the hosting target, whether that is a cloud account, a data center or an air-gapped network, and state the compliance frameworks in scope along with the evidence your assessor expects. Identify named staff for content decisions, test sign-off and cutover approval, and state which PHP or Python skills your team already has and what support model you want after launch. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so gaps in this list usually appear later as change requests.
Can DeployOpen deliver either Drupal or Wagtail on its own?
Yes, DeployOpen can deliver work on either platform, but the platform choice should come from your requirements and team skills rather than from DeployOpen. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies do that work. DeployOpen is not an official partner, reseller or certified provider of Drupal, Wagtail or Torchbox. DeployOpen does not publish a price list, so a quote follows from the written scope.
How DeployOpen helps teams choose and implement either platform
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Drupal vs Wagtail decision, we help you test the fit against your content model, editorial workflow, identity setup and in-house language skills before any build begins.
How we scope
- Written scope lists the content types, editorial roles, workflow steps and sites that Drupal or Wagtail must cover.
- Scope records which identity provider, SAML or OpenID Connect setup, and headless API consumers the platform must serve.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts and a quote follows from that scope.
How we build
- Build work covers the chosen platform's hosting stack, database, web server and PHP or Python runtime inside your environment.
- Content models, templates, editorial workflows and integrations are built and tested against the scope, with security testing run as agreed.
- Deployment, upgrade paths and the release cadence for your chosen version are documented so your team can follow them after go-live.
How we hand over
- Handover includes architecture documentation, runbooks for backups, restores and upgrades, and configuration records for your team.
- Compliance-relevant controls and evidence are prepared for your independent auditors, with DeployOpen preparing systems and records rather than issuing audit reports.
- Training sessions cover the editorial and administrative tasks your staff will own, matched to whether your team works in PHP or Python.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers once the platform is live in your environment.
- Retainers can cover tracking of the Drupal core release schedule or the Wagtail release schedule and planning for the next upgrade window.
- Ask any provider to confirm the support scope, response expectations and upgrade responsibilities in writing before you sign.
