What Drupal customization covers and when teams need it
Drupal customization is the work that makes a standard Drupal site fit your content, your editors and your business rules. It covers content types and fields that model your records, custom modules that implement hooks and services for logic core does not provide, Twig templates that control markup in your theme, Views for listings and queries, and Content Moderation workflows that define who can move content from draft to published. Each of these can be configured in the interface, but once a requirement goes beyond configuration, someone must write and maintain code.
The first decision is whether a need can be met by a contributed module. Drupal and contributed modules are licensed under GPL-2.0-or-later, and there is no license fee for either. Installing a maintained contributed module costs less up front than writing equivalent code, but you inherit its release cycle and compatibility with each Drupal version. Custom code is justified when the business process is specific to your organization, when no contributed module fits the rule, or when a module exists but would need heavy patching to behave correctly.
Typical triggers are a site that has outgrown its default content model, editors who need a defined approval path before publication, and a business process that must be enforced in code rather than left to policy. Ask for a written list of these requirements and check each one against the core modules and maintained contributed projects before scoping any custom work.
Build in-house or with a partner? Teams that already employ Drupal developers who can maintain custom code through each release usually build the work themselves and keep a partner for specialist tasks. Teams without that skill usually need a partner for the initial build and a plan for who will maintain the code afterward. In both cases, the cost is the build effort and the ongoing maintenance of code you wrote, not a license.
What the customization work includes and what you receive
Customization is agreed as a fixed scope in writing before work starts. The work packages below describe what is built, and the deliverables describe what you keep and can run without us.
Content model design
We define content types, fields, taxonomies, reference fields and view modes from your editorial requirements. Each field is checked for its purpose, its reuse across types and its effect on listings and search. Confirm with your editors which fields are required at publish time and which can stay optional.
Editorial workflow with Content Moderation
We configure Content Moderation states and transitions that match your review and approval chain, including which roles can move content between states. Permissions are tested against each role so that editors cannot publish outside their remit. Confirm who approves legal, brand and regional content before the states are named.
Custom module development
Custom logic is written as modules that use Drupal hooks, services and plugins, so it follows core extension points and survives upgrades. Each module is scoped to one business rule or integration. Ask for the list of custom modules and their owners before the build, since each one adds code your team must maintain.
Twig theme build
The theme is built with Twig templates organized as reusable components, with a clear split between markup, styling and logic. Components are documented so that editors and developers reuse them instead of creating one-off templates. Confirm accessibility targets and the browsers you must support before design sign-off.
Views for listings and feeds
Views are configured for listings, filtered feeds and feeds consumed by other systems, with exposed filters, sorting, pagers and caching settings. Each View is checked for query cost and cache tags under realistic content volumes. Confirm the expected content volume and the feed formats your partners require.
Contributed module decision records
For each contributed module, we record why it was chosen or rejected, its maintenance status, its supported Drupal versions and the custom code it would avoid. Rejected options are recorded too, so future maintainers understand the trade-off. Ask for the decision records to be reviewed alongside the upgrade plan, since module compatibility determines upgrade effort.
What drives customization cost and duration
This table lists the main drivers of Drupal customization effort, why each one changes the work, and how teams can keep each one manageable.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Content types and fields | Each type adds fields, display modes, form displays, validation and permissions that must be built, tested and documented. | Reuse existing types, apply entity reference patterns, and agree the content model before build starts. |
| Editorial roles and approval states | Each role needs permissions, and each Content Moderation state needs transitions, tests and training. Rules multiply across content types. | Limit roles to distinct job functions, keep one workflow per content family, and use core Content Moderation before writing custom logic. |
| Custom versus contributed modules | Every custom module is code the team must write, test and carry through each core and contributed module release. | Check contributed options first, configure before coding, and keep custom modules narrow with documented hooks and automated tests. |
| External integrations | Each system adds authentication, data mapping, error handling, retries and monitoring. Partner APIs change on their own schedule. | Confirm API documentation and sandbox access early, route sync through queues, and keep field mapping in one module. |
| Theme complexity | Each page template and component needs Twig markup, styles, responsive behavior and visual review across breakpoints. | Build on a base theme with shared components, limit one-off templates, and approve the component list before design begins. |
| Data volume in Views and queries | Large node or entity counts slow Views, filters and sorts unless indexing, caching and pagination are designed in. | Plan indexes and cache tags, paginate listings, and profile slow Views against production-sized test data. |
| Environments and release process | More environments and manual release steps increase configuration drift, deployment testing and rollback planning. | Keep configuration in version control, deploy through one pipeline, and limit environments to those the team needs. |
| Accessibility and compliance requirements | Accessibility testing, audit trails and data handling rules add review cycles and evidence work for custom components and code. | Name the accessibility standard and conformance level in scope, test custom components early, and record decisions as they are made. |
| Ongoing maintenance of custom code | Custom code must be updated for each Drupal core and contributed release, including monthly bugfix windows and a new major version roughly every three years. | Keep custom code small, add automated tests, track deprecations, and treat maintenance as a recurring cost planned from day one. |
Customization phases and what each one produces
The sequence moves from understanding the content to a tested, documented site your team can run, with a named output at each phase so you can check progress before the next one starts.
Run discovery and content inventory
We review the existing content, templates, user roles, integrations and editorial goals with your stakeholders, then record what content exists, who owns it and where it lives. The step closes with a content inventory and a list of open questions that the scope must answer before design begins.
Design the content model and workflow
Using the inventory, we define content types, fields, references, taxonomies and the editorial states content passes through, including any Content Moderation rules. The outputs are a content model document and a workflow diagram, which your editors and approvers review and sign off before build.
Evaluate contributed modules
For each required capability we check whether a maintained contributed module covers it, how it fits your Drupal version, and what custom code would be needed otherwise. The result is a module decision register recording each choice, the reason for it and the maintenance cost it adds, which you keep as the reference for later upgrades.
Prototype key templates on staging
We build the most important page templates, such as the landing page, article and listing views, on a staging site using the agreed content model. This step closes with a working theme on staging that your editors can click through, so layout and field decisions are tested with real content before the full build.
Build custom modules and the theme
We write the custom modules, hooks, Views configuration and Twig theme for the parts that contributed modules do not cover, following the decisions recorded earlier. The phase closes when the build passes code review and the staging site matches the approved design and model.
Test with editors
Editors and approvers work through their real tasks on staging, including creating content, moving it through each workflow state and checking permissions. We record the results in a test report that lists each defect, its severity and its fix, and the phase closes when the agreed defects are resolved.
Hand over with documentation
We deliver a runbook covering deployment, configuration export and import, module update steps, backups and common editorial tasks, then walk your operations and editorial leads through it. Handover is complete when your team has the runbook, access and a successful deployment performed by them. Ask the written scope for the phase plan with dates.
What teams keep in-house and what they outsource
This table compares each part of a Drupal customization project by who usually does it, and the skills the owning team needs, so you can decide where a partner adds value and where your own staff must lead.
| Activity | Usually kept in-house | Usually outsourced | Skills required |
|---|---|---|---|
| Content strategy and editor sign-off | Yes. Editors, content owners and the business decide what content exists, who owns it and what counts as approved. | Rarely. A partner can facilitate workshops but should not own editorial decisions. | Content governance, editorial process knowledge, stakeholder decision-making |
| Content model and workflow design | Shared. Your team validates the content types, fields and moderation states against real publishing needs. | Often for a first build. A partner drafts content types, fields and Content Moderation workflows, then hands them over with rationale. | Drupal entities and fields, Content Moderation, data modeling, editor usability testing |
| Custom module development | Only if someone on staff writes Drupal PHP and can review it. Otherwise keep ownership of the requirements and acceptance tests. | Yes, if no one on staff writes Drupal PHP. Scope each module against hooks, services and plugins that the core API already provides. | Modern PHP, Drupal services and plugin API, hooks and events, Composer, unit and kernel testing |
| Twig theming and accessibility checks | Accessibility sign-off and content testing stay in-house. Theme maintenance should also be in-house once the handover is complete. | Theme build is often outsourced because it needs Twig, CSS and component work. Accessibility audits can go to a specialist tester. | Twig templates, theme inheritance, CSS and JavaScript, WCAG testing with assistive technology |
| Views and query tuning | Site builders own view configuration and day-to-day changes. Keep a record of which views power key pages. | Performance work on slow views and custom queries is commonly outsourced, using profiling data from your environment. | Views UI and query plans, cache tags and contexts, database indexing, profiling tools |
| Code review and test suites | Your reviewers must approve every merge, including code from a partner, so they can answer for it later. | Test suites are often written during the build. Ongoing test coverage for custom code is a common retainer item. | Code review practice, PHPUnit and kernel tests, CI pipeline configuration, Drupal coding standards |
| Ongoing maintenance of custom code | Yes. Custom modules and themes become your code after handover, so routine fixes, deprecation work and dependency updates should sit with your team. | Available under a support retainer. Confirm response scope, release cadence and who handles Drupal core and contributed module changes that affect custom code. | Drupal version upgrade practice, deprecation handling, Composer, debugging in your own hosting environment |
| Handover and documentation | Your team must be able to read, run and change everything built. Agree the handover standard before the build starts: code standards, documentation, test coverage and a walkthrough. | Partners usually produce the first documentation set and run knowledge transfer sessions. Confirm this is in the written scope. | Technical writing, architecture review, ability to read custom code without the original authors |
What usually goes wrong in Drupal customization and how to prevent it
Most Drupal customization problems come from decisions made early and checked late. Each risk below names the phase where it starts and the step that prevents it.
Custom modules for existing features
Teams often write a custom module for behavior that a contributed module already provides, such as SSO, workflow or media handling. The result is code the team must maintain, test and port to each major version. During discovery, list each requirement against established contributed projects and record why any gap needs custom code before the build starts.
Late content model changes
When content types, fields or taxonomy change after the build, field storage, view displays, menus and migrated data can break in ways that are hard to see. Lock the content model during the design phase with a written field inventory, and route any later change through a configuration review that lists the dependent views and templates.
Editorial workflows built without editors
Content Moderation states, transitions and permissions designed only by developers often fail in daily use, for example when editors cannot find a review step or publish rights are too broad. Include representative editors and reviewers in workflow design, test each transition with a real role account, and document who can move content between each state.
Logic placed in Twig templates
Business rules and data lookups written inside Twig templates are hard to test, repeat across themes and slow to change. Move logic into preprocess functions, components or view configuration, keep templates for presentation, and review each template for queries or conditional business rules during code review.
Code that bypasses APIs and caches
Direct database queries, hard-coded entity loads or custom output that skips the render and cache systems can serve stale content or fail under load. Use entity query, services and cache metadata, and add cache tags and contexts to custom render arrays so that page and dynamic caches invalidate correctly.
Production configuration changes
Settings changed directly in a production admin interface are overwritten or lost when the next configuration import runs from version control. Restrict production admin rights, make every configuration change in a development environment, export it, review it in a merge request and deploy it through the same pipeline each time.
Custom code with no tests or owner
Custom modules without automated tests or a named maintainer tend to break silently during core or contributed updates. Assign an owner to each custom module, add functional tests for critical flows such as publishing and access rules, and keep the test suite running in the pipeline so failures surface before release.
Skipped deprecation checks before upgrades
Custom code that uses deprecated APIs can fail when a new major version of Drupal arrives. Run deprecation analysis on custom modules and themes during each release cycle, not only at the moment of an upgrade, and budget time in the plan to fix flagged items before the upgrade branch is merged.
How customization differs by starting point
A new build on Drupal core starts with a blank slate, so customization covers the whole content model, theme and integration layer. Scope is set by decisions made early, not inherited from a template.
- Content model first: content types, fields, taxonomies and editorial roles are designed before custom modules are written.
- Custom code is a choice: confirm which needs can be met by contributed modules and which need custom modules with hooks or services.
- Theme is built from scratch: Twig templates, component design and Views layouts are all in scope.
- Workflow setup: confirm whether Content Moderation states and transitions must be designed around approval paths.
- Confirm first: the target Drupal major version and its PHP requirement, since they determine which contributed modules are usable.
A site started from Drupal CMS inherits recipes, a site template and optional Drupal Canvas pages. Customization is about what the recipes do not cover, and about changing recipe output without breaking future updates.
- Audit the recipe output: list the content types, views, and configuration the recipes created before adding anything.
- Extend, do not fork: custom modules should sit beside recipe-created configuration so that later Drupal CMS updates remain manageable.
- Identify gaps: integrations, custom business rules and specialized forms often need custom development that recipes do not provide.
- Confirm first: which Drupal CMS major release is in use, and whether optional AI tools are enabled and approved for your data.
An existing Drupal 10 or 11 site is extended in place, so the work starts with the code and configuration already in production. Scope depends on how well the current codebase follows Drupal's configuration and Composer practices.
- Review the current codebase: check custom modules, deprecated API usage and contributed module versions before adding features.
- Keep configuration in sync: new fields, views and roles should be exported and tested through the configuration management workflow.
- Plan around upgrades: Drupal 10 reaches end of life on December 9, 2026, so new custom code should be written to run on Drupal 11.
- Confirm first: the installed core version, PHP version and whether every contributed module has a release for the target version.
A Drupal 7 site cannot be updated in place to a modern version, so customization runs alongside a migration into a new site. Because themes cannot be migrated, the theme is rebuilt, and that rebuild is often the largest customization item.
- Rebuild the theme: the Drupal 7 theme is rebuilt in Twig, so visual design and template work are scoped as new development.
- Rewrite custom modules: Drupal 7 custom code is not carried forward and must be reimplemented against current APIs.
- Check contributed module paths: some modules have no migration path, so each needs a replacement, a custom build or removal.
- Plan the stopgap: Drupal 7 security support ended on January 5, 2025, so extended support may be needed while the new site is built.
- Confirm first: which modules and features are in use and which ones your content and editors depend on.
In a self-hosted or air-gapped environment, Composer packages and contributed modules cannot be pulled directly from public sources at build time. They must be mirrored and vetted before use, which adds a supply chain step to every customization.
- Mirror dependencies: Composer packages, contributed modules and core releases are copied into an internal repository before a build can use them.
- Vet each module: review license terms, maintenance status and security advisories before a module enters the approved list.
- Build the update path: monthly bugfix and third-Wednesday security releases must be mirrored on a schedule your change process can absorb.
- Confirm first: the database and web server options your environment supports, and the approval process for new modules and custom code.
What you need to provide before customization starts
Customization work stalls quickly when decisions have no owner. Before the build starts, name one product owner and one editorial lead, and give both written authority to approve content types, fields, workflow states and launch criteria. If either role is shared with a committee, confirm in the written scope who breaks a tie and how long a decision can wait.
Next, supply the content inventory and a sample of real pages, documents and media. The sample should include the awkward cases: long articles with embedded media, pages with legacy shortcodes or hand-coded HTML, and content that moves through an approval chain today. Existing workflow documents and approval rules matter as much as the content, because the Content Moderation states and transitions you configure should match how people actually sign off, not a generic draft-review-publish pattern.
Provide brand guidelines, design files and your accessibility standard, including the conformance level your organization must meet and any internal testing practice. Also confirm access to the staging and production environments, the code repository and the hosting account, with named administrators. Decide which contributed modules are approved for use before development starts, since each approval changes what custom code is needed. Finally, list every external system the site must read from or write to, and name the internal developer who will own the code after handover.
Frequently asked questions about Drupal customization
How much does Drupal customization cost?
Cost depends on the written scope, so there is no standard figure. The main drivers are the number of content types and fields, how many custom modules and integrations are needed, how much theme work goes beyond the base theme, and how many editorial workflows must be configured. Drupal itself has no license fee, so the cost is the build, testing, and the effort to keep custom code working. Ask for a quote that lists each deliverable, the assumptions behind it, what is one-time work, what recurs (such as upgrade and support effort), and which items depend on access to your systems.
How long does a Drupal customization project take?
Timelines are set by scope and agreed in writing before work starts. The biggest factors are the number of custom content types, the complexity of integrations with external systems, how many approvals your content workflow requires, and how quickly your team can answer questions and review builds. Ask the vendor to break the timeline into discovery, build, testing, and launch phases, and to name the dependencies on your side, such as identity provider access, test data, and sign-off owners.
Can our in-house team customize Drupal without a partner?
Yes, if you have people who can write PHP, work with Drupal's hook and service APIs, build Twig themes, and run automated tests. Many teams do this well. The questions to answer honestly are how many people can maintain custom code over several years, who reviews security advisories, and how upgrades will be planned. Custom modules become part of your long-term codebase, so the real cost is ongoing maintenance, not the first build.
When should we use a contributed module instead of custom code?
Use a contributed module when it already meets the requirement, is actively maintained, and supports your Drupal version. Custom code makes sense when the business rule is unique, when no module covers it, or when a module adds far more features than you need. Check the module's release history, issue queue, maintainer activity, and compatibility with the Drupal version you plan to run. Every custom module you add is code your team must test and upgrade.
Which PHP version does Drupal require?
Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later, according to the Drupal.org PHP requirements page. No supported Drupal version runs on PHP 7. Confirm the PHP version your hosting platform offers before you choose a Drupal major version, and check that every contributed module and custom module you plan to use works with it.
What do we need to provide for a Drupal customization project?
Most projects need a named business owner who can approve content models and workflows, access to existing content and data for analysis, and access to any systems the site must integrate with. You will also need hosting or infrastructure you control, accounts for source control and deployment, and staff available for review sessions and user acceptance testing. Agree these inputs in the written scope so that delays caused by missing access or decisions are visible and can be planned for.
How DeployOpen scopes, builds and hands over Drupal customization
DeployOpen plans, builds, documents and supports Drupal customization inside infrastructure you control, starting from a written scope agreed before work begins. The work follows a path from scoping through handover to ongoing support, so your team can run and extend what gets built.
How we scope
- Review content types, fields, roles and editorial workflows to decide what needs custom code and what a contributed module already covers.
- Record which Views, Content Moderation states and Twig templates are in scope, with the acceptance criteria for each.
- Confirm the Drupal version, PHP version and database target so custom code matches the platform your team will run.
How we build
- Build custom modules, hooks and Twig theme components in version control, with Composer managing contributed dependencies.
- Test custom code and configuration changes in non-production environments before any change reaches production.
- Keep contributed module choices documented, including why a custom alternative was or was not needed.
How we hand over
- Deliver a written record of custom content types, fields, modules, hooks, theme structure and configuration export files.
- Walk your developers and editors through the editorial workflow, Views configuration and the deployment steps they will repeat.
- Hand over source repositories, environment notes and a list of open items agreed in the written scope.
How we support
- Offer ongoing support, upgrades and testing as a retainer, scoped separately from the original build.
- Plan contributed module compatibility checks against Drupal core release windows so custom code keeps working through updates.
- Ask for the retainer terms in writing, including which custom code, environments and release windows it covers.
