Drupal implementation plan and cost

What a Drupal implementation involves

Drupal core and its contributed modules carry no license fee. Drupal and contributed files on Drupal.org that are derivative works of Drupal are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself. The cost of a Drupal implementation therefore comes from the work around the software: discovery, content modeling, build, integrations, hosting and ongoing support. When you request a quote, ask for each of these as a separate line so you can see who is paid for what and which items recur after launch.

Most projects start from one of three triggers: replacing an aging site, launching a new product or market that needs its own content and workflows, or moving off a commercial CMS. Each trigger changes the discovery work. A replacement site needs an inventory of existing content, URLs and integrations. A new market adds languages, approval paths and possibly separate teams. A move from a commercial CMS needs a content and template mapping before any build estimate is meaningful. Ask the partner to show how they would scope each of these for your case.

The current major version is Drupal 11, which requires PHP 8.3 or later. Drupal 10 requires PHP 8.1 or later and Drupal 12 requires PHP 8.5 or later. Before committing to a build, confirm that your hosting platform, operating system packages and any contributed modules you plan to use support PHP 8.3 and Drupal 11. Drupal 7 security support ended on January 5, 2025, so any Drupal 6 or 7 site should be treated as a migration decision rather than a build input.

Build in-house or with a partner: a team with existing Drupal developers, an agreed architecture and capacity for ongoing maintenance can often build in-house. A partner is usually worth considering when the team lacks Drupal experience, the timeline is fixed, or the platform must be hardened and documented for an assessment. Migrating a Drupal 6 or 7 site and upgrading a Drupal 10 site to Drupal 11 are separate services with their own scope, so plan and price them separately. Those services are offered as the Drupal 7 migration and the Drupal upgrades and support topics.

What the work includes and what you receive

A fixed-scope Drupal build usually moves through the packages below, each ending in a written deliverable you can review. Ask for these deliverables by name in any quote so the scope can be compared across proposals.

Discovery and requirements

Discovery records the sites purposes, audiences, editorial roles, existing systems and compliance obligations. The output is a signed scope document with a requirements register, open decisions and named owners. Check that every integration and every content source appears in the scope, because those items drive most cost changes later.

Content model specification

The content model specification lists content types, fields, taxonomies, references, revision rules and editorial workflow states. Your content owners should approve it before theme work begins, since templates and views depend on it. Check whether the specification covers translations and whether it reflects the content you will actually import.

Starting point decision

The team chooses between Drupal core and Drupal CMS, which is a distribution built on core with recipes, site templates, the Drupal Canvas visual page builder and optional AI tools. The output is a short decision record that names the recipes adopted, the contributed modules selected and the custom code still required. Ask for this record before the build quote is final.

Custom modules and theme

Custom modules and the front-end theme are delivered as a codebase in your repository, managed with Composer and configuration export. Each custom module comes with a README, its configuration and tests where agreed. Confirm who owns the repository, which branch policy applies and how contributed module versions are pinned.

Integrations and environments

Integrations and environments cover the connections to identity, CRM, search and other systems, plus the development, staging and production environments on infrastructure you control. Deliverables include an integration specification, environment documentation and a runbook for deployment and rollback. Ask which web server, database and PHP version the environments will run, based on current Drupal system requirements.

Testing, content load and handover

Testing covers functional checks, accessibility and cross-browser review, and a content import rehearsal before cutover. Handover includes training sessions for editors and administrators, along with the codebase, documentation and runbook. Ask what the acceptance criteria are, who signs them off and whether post-launch fixes are covered by the fixed scope.

What drives cost and duration

The table lists the factors that most often move the scope, effort and calendar of a Drupal build, why each one matters and what to do to keep it under control.

Driver	Why it moves cost	How to keep it down
Content types and fields	Each content type needs its own fields, view modes, forms, permissions and test cases, and every reference between types adds modeling and QA work.	Model only the content the site must publish, reuse fields across types, and agree the content model in discovery before build starts.
Editorial workflow complexity	Multi-stage approvals, role-specific forms and scheduled publishing add configuration, permission testing and training material.	Start with the approval steps the business requires today and use Content Moderation with a small number of states.
Number of integrations	Each CRM, identity, search, payment or ERP link needs an agreed data contract, error handling, test data and monitoring. Integrations often take more effort than the Drupal side.	Confirm which systems are authoritative for each data item, and phase lower-value integrations after launch.
Custom modules versus contributed modules	Custom code is written, tested, documented and maintained by someone for the life of the site. Contributed modules reduce build work but need compatibility checks at each upgrade.	Choose maintained contributed modules where they fit, and limit custom code to business rules that no existing module covers.
Theme design depth and component count	A custom theme with many distinct components, responsive layouts and interaction states needs design, Twig templating, browser testing and accessibility review for each one.	Reduce the number of unique templates, reuse components, and sign off the design system before page-level build.
Environments and hosting model	Each environment needs provisioning, configuration sync, data refresh and deployment steps. Own cloud, data center and air-gapped hosting each add different infrastructure, patching and offline package work.	Agree the minimum environments needed, automate provisioning, and confirm the hosting model and its constraints before estimating.
Accessibility and compliance evidence	Accessibility testing, audit logging, retention settings and evidence collection add test cycles and documentation. DeployOpen prepares evidence, but independent assessors issue any audit results.	Name the target standards and the evidence the assessor expects at the start, and keep the requirements to those the site must meet.
Number of languages	Each language adds translation workflow, URL patterns, configuration translation, content review and testing across templates.	Limit launch languages, confirm which content is translated and by whom, and plan later languages as a separate phase.
PHP and database versions chosen	Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later (Drupal.org PHP requirements page). Older runtimes or a database not already in your standards can add platform work.	Pick the Drupal version and PHP runtime your organization already supports, and confirm the database choice from MariaDB, MySQL, PostgreSQL or SQLite.
Migration from Drupal 7	Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later. Content, configuration and themes are migrated or rebuilt, which adds audit and reconciliation effort.	Run a content and module audit early, retire unused content, and confirm which contributed modules have migration paths.

Project phases and what each produces

The sequence moves a Drupal project from agreed scope to a launched site with a supported handover, and each phase ends with a written output that the next phase depends on.

Run discovery and agree scope
The partner and your stakeholders map content types, editorial roles, integrations, traffic expectations and hosting constraints. Your team reviews the findings and signs a written scope with deliverables. The phase closes when the scope document, integration inventory and open-question list are approved by the business owner.
Model content and information architecture
Content types, fields, taxonomies, menus and editorial workflows are designed on paper before any build. Engineers and editors review sample content flows and decide which items are core fields and which are custom entities. The gate is an approved content model and sitemap that the build team can implement without further questions.
Decide the starting point and architecture
Drupal core, Drupal CMS or a hybrid is chosen against the content model, the team's skills and the contributed modules needed. Hosting, PHP version, database, caching and identity approach are recorded in an architecture decision record. Confirm the PHP and database requirements for the chosen Drupal version with the vendor documentation before hosting is ordered.
Design the theme and key templates
Visual design, component library and Twig templates are produced for the main page types, with the content model applied to real sample data. Your brand owner approves the designs, and the engineering team confirms they map to the planned fields and views. The output is an approved design set and a theme skeleton in version control.
Build custom modules and integrations
Custom modules, contributed module configuration, and integrations with identity, CRM, search or other systems are built against the architecture record. Each integration is tested against a non-production endpoint with agreed data samples. The phase closes when features pass the agreed test suite in a staging environment and integration owners sign off.
Migrate or enter content
Existing content is migrated with scripted migrations, or entered by editors, according to the audit from discovery. Migrated records are reconciled against source counts and sampled by editors for accuracy. The gate is a reconciliation report that the business owner accepts, listing any content deliberately left behind.
Test, review accessibility and go live
Functional, regression, performance and accessibility reviews run against staging, and defects are tracked to closure. Hosting is handed over with runbooks, access records, backup evidence and monitoring, and cutover is rehearsed before the launch date. The phase closes with a signed go-live checklist and a handover document covering support contacts and update procedures.

What to keep in-house and what to outsource

This table shows who typically owns each part of a Drupal build, what skills that owner needs, and where a partner's work ends and your team's begins.

Work area	Typical owner	Skills needed
Product ownership and content strategy	In-house	Clear decision rights, audience and content priorities, and authority to sign off scope changes during the build
Information architecture and content modeling	Shared	Your editors describe how content is written and reused, while the partner turns that into content types, fields and taxonomy
Drupal architecture and custom module development	Often outsourced unless you have Drupal depth	Drupal core APIs, entity and field design, hooks and services, and Composer-based dependency management
Theming and front-end build	Often outsourced, with in-house design review	Twig templating, the theme layer, accessible markup, and a build pipeline your front-end staff can maintain
Integration engineering with identity and CRM systems	Shared, with your identity and CRM owners	SAML or OpenID Connect configuration, role mapping from identity attributes, and API access to the CRM
DevOps and hosting	In-house, or a managed partner you contract	Web server, PHP and database administration, deployment pipelines, backups and monitoring in your environment
Security review	In-house owner, with independent testing	Permissions review, settings and file protection, patch monitoring against Security Team advisories, and vulnerability triage
QA and accessibility testing	Shared, with a dedicated tester on your side	Test case writing, cross-browser and assistive technology checks, and regression testing before each release
Editorial training and handover documentation	Partner delivers, in-house owns afterward	Facilitation for editors and site builders, plus a runbook your team can follow without the partner

What usually goes wrong and how to prevent it

Most Drupal builds that overrun do so for predictable reasons. Each card names one failure mode, the prevention step, and who should own the decision.

Scope set before the content model

Teams often sign a fixed scope by page count or feature list before content types, fields and relationships are agreed. Later changes to the model then ripple through templates, Views, permissions and migration. Prevention: agree a content model workshop output, with content types, required fields and editorial owners, before the scope is priced. The client owns the content decisions; the partner proposes the model and tests its impact on the estimate.

Custom code where a module fits

Custom modules are sometimes written for needs that a contributed module already covers, such as редирект handling, workflow states or SEO metadata. Each custom module then needs upgrading with every Drupal major release. Prevention: before scoping any custom feature, check the contributed project's maintenance status and Drupal 11 compatibility. The partner recommends; the client approves any custom code that will be maintained long term.

Unclear content type and role ownership

When nobody is named as owner of a content type or editorial role, field definitions, moderation states and access rules drift after launch. Prevention: write a roles matrix that lists who creates, reviews and publishes each content type, and map it to Drupal roles and Content Moderation transitions. The client names the business owners and their approvers; the partner configures the roles and documents them.

Integrations found late in the build

Single sign-on, CRM, search, payment or document systems are sometimes discovered during testing, when their data formats and authentication requirements no longer fit the build. Prevention: inventory every system the site reads from or writes to during discovery, and record the protocol, data owner and test access for each. The client supplies system owners and test credentials; the partner scopes the integration work per system.

Hosting and environments left undefined

Teams that have not decided where Drupal runs, which PHP version it uses, or how development, staging and production relate to each other tend to find out at launch week. Drupal 11 requires PHP 8.3 or later, and the database and web server choices affect the deployment design. Prevention: fix the hosting target, PHP version, database and environment list in the plan, and agree how configuration moves between environments. The client decides where hosting runs; the partner documents the build and deployment path.

Theme not reviewed for accessibility

Themes built for visual design sometimes fail keyboard navigation, colour contrast or screen reader support, and the defects surface only in a late audit. Rework on templates and components is then costly. Prevention: name the accessibility standard the client must meet, include it in the design review, and test templates with automated checks and manual keyboard and screen reader passes before sign-off. The client sets the requirement and accepts the evidence; the partner builds and tests against it.

Launch date fixed before test capacity

A launch date set during sales or budgeting often ignores how many people can test content, integrations and editorial workflows in the time left. Testing then gets cut first, and defects reach production. Prevention: size the test effort from the agreed content model and integration list, name the testers and their availability, and set the launch date only after that plan is accepted. The client commits testers and sign-off dates; the partner proposes the test plan and its effort.

How the build changes by starting point

Start from Drupal core when the content model, editorial process and front end are specific enough that a prebuilt starting point would need heavy removal. Discovery takes the most time because every content type, field and workflow is designed from scratch.

Scope: content modeling, custom modules, a custom theme and all configuration are in scope from the first sprint.
Phases: discovery and content model, build and theming, content migration if needed, verification, then launch.
Cost drivers: the number of content types, custom integrations and theme complexity.
Recurring costs: contributed module upkeep, hosting and upgrades to Drupal 11 or later. Drupal carries no license fee under GPL-2.0-or-later, so the budget goes to build and operations.
Evidence: DeployOpen prepares configuration and test evidence for your assessors. It does not issue audit reports or certifications.

What you need to provide before work starts

The fastest way to keep a fixed-scope Drupal project on its written timeline is to have these inputs ready before discovery begins. Each item removes a question that would otherwise be answered mid-build, and each unanswered question is a common source of change requests. Ask for them in writing at the start, and confirm the named people can give the time the plan assumes.

Start with people. Name one product owner who can rule on content types, page structures and editorial workflow without waiting for a committee, and list the decision-makers who must approve the written scope, budget changes and go-live. Approval authority matters as much as the names: confirm who can sign a scope change and how quickly they respond. Also name the owner for content after launch, since that person's editors shape the content model, the Content Moderation workflow and the rules for reusable blocks and menus.

Next, provide a content inventory and sample content. A spreadsheet of existing pages, documents and media, with owners, languages and rough volumes, lets the team model content types and fields during discovery rather than after it. Include real examples of long articles, landing pages and forms. Brand assets, such as logos, color tokens, font licenses and style guides, feed the Twig theme directly. Written accessibility requirements, including the conformance level your policy sets, should be stated up front, because they change theme markup, form handling and testing effort.

Finally, collect the technical details. List every integration with its owner, access method and test accounts, such as CRM, payment, search or HR data sources, and confirm that test environments exist for each. Confirm hosting and network access in your environment: the web servers, database, file storage and PHP version you will run, and how DeployOpen will reach them. If single sign-on is in scope, provide the identity provider metadata, attribute names for role mapping and a decision on how local administrator accounts are kept. Missing any of these usually moves work into later phases.

Common questions about Drupal implementation cost and effort

Does Drupal have a license cost for a custom build?

No. Drupal and the contributed files hosted on Drupal.org are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself. Cost comes from the work and the running environment: discovery, content modeling, custom modules and theme, integrations, hosting, and the contributed modules you choose. Those modules are free to download but still need evaluation, updates and testing. Ask the partner to separate one-time build fees from recurring hosting, support and upgrade effort in the quote.

Should we start from Drupal core or Drupal CMS?

It depends on how much of the site your marketers will build themselves. Drupal CMS is a distribution built on Drupal core for marketing and content teams, with recipes, site templates, the Drupal Canvas visual page builder and optional AI tools. Drupal CMS 2.0 is the current major release. Bare core gives more control over content types, editorial workflows and custom code from the start. Before you commit, confirm which recipes and contributed modules the design needs and whether Canvas covers your page layouts.

How long does a Drupal implementation take and what sets the length?

No single duration fits every site, so the timeline should come from the written scope. The main drivers are the number of content types and integrations, the amount of custom module and theme work, how many contributed modules need evaluation, the volume of content to migrate, and the number of review rounds on design and content. Ask for phases with a milestone and acceptance criteria for each, so you can see where the time goes and what each sign-off unlocks.

What must our team provide and what does the partner handle?

Your team owns decisions and access, and the partner owns the build. You typically provide business owners who can approve content models and workflows, content sources and sample data, existing system documentation, integration credentials, and hosting accounts in your cloud or data center. You also need timely sign-off at each phase. The partner plans, builds, configures, tests, documents and hands over the site. Confirm this split in a responsibilities table within the scope before work starts.

Can an internal team build a Drupal site without a partner?

Yes, if the team includes Drupal engineers who can own PHP, Composer, configuration management and security patching after launch. Drupal 10 requires PHP 8.1 or later and Drupal 11 requires PHP 8.3 or later. The harder question is capacity: discovery, content modeling, integrations and testing compete with daily work, and the team must follow monthly bugfix releases and third-Wednesday security releases. Compare internal effort with a scoped partner quote, including the first major version upgrade.

What should a fixed-scope quote say about changes and exclusions?

A fixed-scope quote should list deliverables, not just hours. Look for the content model, the custom modules and theme components, each integration with its data flow and credentials owner, the contributed modules selected, the migration scope, testing and acceptance criteria, and training. It should also state what is excluded and how many review rounds are included. Changes should go through a written change request that shows the effect on scope, timeline and cost before work starts. Confirm the payment milestones and who approves each change.

How DeployOpen scopes and delivers Drupal builds

DeployOpen plans, builds, documents and supports Drupal inside your own infrastructure, with the scope, deliverables and timeline agreed in writing before work starts. The cost follows from that written scope, so the plan is the basis for every quote.

How we scope

Discovery records content types, user roles, editorial workflows, integrations and hosting constraints before any build estimate is written.
The written scope states whether the starting point is Drupal core or Drupal CMS, and why, with the reasoning kept on record.
Each deliverable, the phases that produce it and the acceptance criteria are listed so you can compare quotes on the same basis.

How we build

Content modeling, custom modules and theme work follow the agreed scope, with contributed modules chosen only where they fit the requirement.
Configuration is kept in version control and moved between environments with Drupal's configuration management, so changes are reviewable.
Testing covers content workflows, integrations, permissions and the hosting stack, with results recorded against the acceptance criteria.

How we hand over

Handover includes the code repository, configuration export, deployment steps and environment documentation for your own team to run.
Documentation covers custom module behavior, integration endpoints, credentials handling and the PHP and database versions the site requires.
Your team receives a walkthrough of editorial workflows and admin tasks, with the open items from the scope listed explicitly.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, so the post-launch effort is priced separately from the build.
A support plan should name who applies monthly bugfix and security releases and how contributed module updates are reviewed.
Ask any partner to confirm how it will track Drupal 10 end of life on December 9, 2026 and the planned move to Drupal 11.