Case Studies

Last updated on
21 October 2026

Case studies on Drupal.org show the world what's possible with Drupal. They're written for non-technical evaluators: the people comparing platforms and deciding whether Drupal fits their organization. A strong case study does more than describe a website. It proves an outcome.

We want the library to capture the full breadth of what's built with Drupal: small nonprofits and large universities, governments and global corporates, projects across countries and languages. Within that breadth, we're especially looking for the best and most trusted brands in each industry. These are the reference points that give evaluators confidence and move the needle for everyone else considering Drupal in that sector.

Featured case studies appear in the case study overview, rotate through the Drupal.org homepage carousel, and supply the proof points used in keynotes, marketing campaigns, and community advocacy content. The better your evidence, the further your case study travels.

Why submit a case study

A published case study gives your project and organization lasting visibility with the people evaluating Drupal.

  • They join the case study library on Drupal.org, the first place many evaluators look. Outstanding entries rotate through the homepage carousel
  • They earn your organization contribution credits
  • They're featured on Drupal's social media channels
  • They become a lasting proof point and reference for your potential clients, and source material for keynotes, campaigns, and community advocates

What makes a case study we feature

The best case studies prove something. Before you write, gather answers to these six questions. They're what our editors look for when choosing which case studies to feature.

1. What changed, in numbers? Include at least two specific metrics, ideally before-and-after: page load time, conversion rate, cost per site, time-to-publish, editorial hours saved, sites consolidated, traffic growth. "Improved the user experience" tells us nothing. "Cut average publishing time from 3 days to 4 hours" tells the whole story.

2. Why did they move, and why then? Every migration has a trigger: a platform reaching end-of-life, unsustainable licensing costs, a compliance deadline, an acquisition, a redesign the old system couldn't support. Name it. Evaluators reading your case study are usually facing the same trigger.

3. How has the site grown without a rebuild? One of Drupal's strongest arguments is that sites evolve in place without a costly replatform. New features, major version upgrades, and AI capabilities can all be added to the site you already have. If the site has been upgraded or extended since launch, say so and say how long it took.

4. What standards does it meet? Accessibility (such as WCAG conformance), privacy (such as GDPR), security certifications, government or sector-specific compliance. Regulated organizations choose Drupal partly for this, so give them the evidence.

5. Who can do what, without a developer? Describe at least one thing marketers or content editors now do themselves: launching landing pages, managing multilingual content, running campaigns. Drupal is evaluated by technical and non-technical buyers. Show it working for both.

6. What's the one-sentence outcome? End your results with a single sentence someone could quote in a presentation: "[Organization] consolidated 40 sites onto one Drupal platform and cut hosting costs by half." If you only polish one sentence in your case study, make it this one.

How to structure your writing

Lead with the outcome, then tell the story.

  • Results first. Open with a short Results section containing your metrics and your quotable sentence. Readers decide in the first paragraph whether to keep going.
  • Goal, challenge, solution. Then explain what the organization needed, what stood in the way (including the trigger for change), and how Drupal solved it.
  • Benefits as a list. Use point-form lists for benefits and features rather than long paragraphs.
  • 750 words maximum. Shorter is fine. The metrics and images carry more weight than the prose.
  • Make Drupal the subject. Highlight the value Drupal brought, not just the agency that delivered the project.

Completing the submission form

Case studies are submitted through the Create Case Study form on Drupal.org. Most of your proof points land in two fields: the trigger and platform comparison belong in Why Drupal was chosen, while your metrics, standards, and quotable outcome belong in Describe the project. Fields marked * are required.

Field

What to put there

Project name

The organization or site name, not the agency name.

Primary screenshot *

The site's homepage, unless another page makes a stronger case. No drop shadows or white space on the edges.

Cover photo

A simple photo relating to the site or organization, not a screenshot or a stock image of devices. Choose a low-contrast image so the title text stays readable over it.

Sectors

Choose one or two sectors that best fit the project. These power the filters evaluators use, so pick the sectors a prospective customer would search.

Summary

A standalone one- or two-sentence summary shown in listings. Use your quotable outcome sentence here. Don't leave it to auto-trim.

Brief overview

The business case in brief: lead with the results, then the background and the organizations involved.

Completed site or project URL *

The live site, as a full external URL.

Why Drupal was chosen *

The operational trigger for the change, which platforms were considered, and why Drupal met the project's needs.

Describe the project

The main body. Cover the goal, challenge, solution, and outcomes, including your metrics, standards met, and what editors and marketers can now do themselves. Maximum 750 words.

Technical specifications

The Drupal version and key modules, themes, or distributions, selected via autocomplete, which credits their maintainers. Explain why they were chosen here, and keep module names out of the main narrative.

Community contributions

Anything given back: patches, modules, themes, documentation, new contributors who joined through the project.

Team

Organizations and team members via autocomplete where they exist on Drupal.org. Everyone else goes in the free-text field.

Additional screenshots

Two or three screenshots of different pages or significant features. Include alt text for accessibility and search.

File attachments

Images to embed within the case study body. They aren't displayed by default.

By submitting, you confirm you have the end-user organization's permission to reference their organization and project. Get this approval before you start writing, not after.

Images

Images are often what makes a case study feel real to an evaluator. All images should:

  • Screenshots should show real pages, features, and workflows. Editorial screens are as persuasive as public-facing pages
  • Polished brand or editorial photography is welcome too, especially as the cover photo or embedded in the body, where it helps tell the organization's story
  • All images must be high-resolution and accessible, with alt text and titles
  • Optimize images for the web: upload them pre-scaled, with unnecessary metadata removed

Style rules

In addition to the Drupal.org content style guide:

  • Speak to benefits in specific terms. Name the experience that improved, not just "better UX"
  • Avoid jargon and Drupalisms. Module names belong in the Technical specifications field, not the story
  • Spell out abbreviations and acronyms on first use
  • Use gender-neutral pronouns
  • Follow the Drupal Code of Conduct

Promotional material

Per the Drupal.org advertising guidelines, do not include promotional material, calls-to-action, or lead capture forms in your case study. These are reserved for organizations in the Drupal Association Supporting Partner Program at the Premium level and above. Any lead capture CTA and premium placement on the case study page is implemented by Drupal Association staff. Premium Supporters and above who want to learn more should contact their account manager.

Submit a case study

Ready to go? Submit your case study. 

Help improve this page

Page status: No known problems

You can: