Drupal multisite alternative: keep Drupal for the flagship, rethink the long tail
Drupal is the CMS large public bodies and universities trust with their biggest, most structured sites, and for those it is often the right call. Drupal multisite stretches the same codebase over many smaller sites. That works while you have a Drupal team to match. When a department wants a five-page site and the queue to get one is three months long, the problem is not Drupal; it is using a flagship tool for a long-tail job.
TL;DR
- Drupal's documentation: multisite serves 'separate, independent sites' from one codebase; each has its own database, configuration, files and domain.
- Shared code means one upgrade path for every site, and every site waits for the slowest one. Drupal 7 security support ended on 5 January 2025, which forced many networks to face this.
- We.Inc runs the long tail: each department or chapter gets its own AI-built site under your brand, with central rules and single-step approval before publishing.
- A split is usually best: Drupal for the main site and structured content, a builder for small sites.
What Drupal multisite is
The Drupal documentation puts it in one line: "Drupal has a feature that allows separate, independent sites to be served from a single codebase." And: "Each site has its own database, configuration, files and base domain or URL."
That is a different shape from WordPress Multisite. Drupal sites in a multisite setup share code (core, modules, themes) but not data. The benefits are real: one place to patch, one set of modules your team has reviewed, independent content per site. The cost is that every site moves at the speed of the shared code. A module update, a core upgrade or a PHP version change is a change to all of them.
The upgrade wall
Most organisations discovered the cost of shared code at a major version change. Drupal's own site states that "Drupal 7 security support has ended as of 5 January 2025" (Drupal 7 end of life). A network of 150 Drupal 7 department sites did not have one upgrade to plan; it had 150 content migrations onto a new major version, plus every custom module and theme.
If you went through that, or are still in it, it is worth asking which of those 150 sites ever needed Drupal. A typical answer from university and city web teams looks like this:
| Site type | Typical share of the network | Needs Drupal? |
|---|---|---|
| Main site, news, directory, course or service catalogue | A handful | Often yes: structured content, integrations, many editors |
| Large departments with their own content types | Some | Sometimes |
| Small departments, programmes, labs, events, chapters | Most | Rarely: a few pages, one editor, occasional changes |
| Campaign and one-off sites | Many, short-lived | No |
The last two rows are where a Drupal team's time disappears: requests for new sites, editors who forget how the admin works, and sites nobody owns any more.
What a builder does differently for those rows
In We.Inc, each small site's owner is an account under your brand. They sign in to a portal with your name and colours, describe the site they need, and the AI builds it. They edit it visually. You decide centrally what they may do and whether their changes wait for approval.
*Brand settings applied across every owner's portal: logo, colours, font, button style.*
*The portal your site owners sign in to is designed once, centrally.*
There is no module list to keep secure across a network, because features (blog, forms, store, SEO settings) are part of the builder and switched on per owner. There is no shared upgrade to schedule.
*Per-owner switches. A lab gets a blog and forms; a short campaign site does not need a store or its own domain.*
Where Drupal is clearly the better tool
We would rather you kept Drupal than bought the wrong thing:
- Structured content at scale. Course catalogues, staff directories, service finders and anything with many fields and views.
- Deep integrations. Student systems, identity systems, payment gateways and data feeds your developers have built against Drupal.
- Complex editorial workflow. Multi-stage review with several roles in sequence. Our approval is single-step: a site goes live when the brand owner approves it.
- Fine-grained roles. Drupal's permission system is far more granular. Ours is owner, admin and member, plus fixed staff presets and per-owner switches.
- Teams with Drupal developers who are productive and happy.
A split architecture that works
The pattern we see work is not "replace Drupal" but "stop putting everything in Drupal":
- Keep the flagship and the structured sites in Drupal. These are the sites that justify its cost.
- Move small sites to the builder in batches. Rebuild from content, not by porting themes. Redirect old URLs.
- Use the same brand standards in both. Colours, logo and fonts set in the builder's brand settings to match the Drupal theme.
- Link, do not embed. Small sites link back to the main site's directory or catalogue rather than copying it.
- Write one governance policy for both. Who can request a site, who approves it, when it is reviewed and when it is retired. Our governance policy template has wording.
*The approval queue for sites whose owners need sign-off. One step, by the brand owner.*
Questions to put to any long-tail platform
Whether or not you choose us, ask these before moving small sites off Drupal:
| Question | Why it matters | Our answer |
|---|---|---|
| Can we get every site's code out? | Avoids the next forced migration | Yes: download as ZIP or sync to GitHub |
| Who can publish without review? | Policy and reputational risk | Per owner, with single-step approval |
| Is there a record of who changed settings? | Accountability | Audit log of organisation actions |
| Can each site have its own domain? | Departments often have legacy domains | Yes, when you allow it for that owner |
| What accessibility does the output meet? | Legal duty for public bodies | Built to help you meet WCAG 2.1 AA; your team must test |
| What certifications do you hold? | Procurement | We do not claim any; ask for our security documentation in the demo |
*Exporting a site: to GitHub, as a ZIP, or elsewhere. Your next migration, if there is one, starts from real code.*
For public bodies, the accessibility duty applies whatever platform you use. Our ADA Title II deadline guide explains the dates. This is general information, not legal advice.
Book a demo with your list of Drupal sites and we will mark which ones we would move and which we would leave alone.
Sources
Last checked 2026-10-25.
- Drupal.org, Multisite Drupal: single codebase; own database, configuration, files and domain per site.
- Drupal.org, Drupal 7 end of life: security support ended 5 January 2025.
Book a demo. Pricing is tailored to your volume and setup, and you get your exact price on the call. 0% transaction fee.
Frequently asked questions
Is Drupal multisite the same as WordPress Multisite?
No. Drupal's documentation describes multisite as separate sites served from one codebase, each with its own database, configuration, files and domain. WordPress Multisite shares one installation and database with per-site tables.
Should we replace our main Drupal site with We.Inc?
Usually not. Large structured sites with integrations and complex workflow are where Drupal is strong. We.Inc fits the many small sites around it.
Does We.Inc have multi-stage editorial workflows?
No. Approval is a single step: an owner presses Publish and the site goes live when the brand owner approves it. Further sign-off stages need to happen outside the platform.
Is this legal advice about accessibility deadlines?
No. It is general information. Check the rules that apply to you with your own counsel.
Keep reading
- White-label builder vs enterprise CMS: a fit guide
- White-label websites for universities
- White-label websites for government agencies
- Website governance policy template
- Website vendor exit plan: contract clauses
- ADA Title II website deadline explained
More in White Label
- Duda white label pricing in 2026, and the AI alternative
- Websites for the projects, partners and small businesses an EDO serves
- Every event needs a website for about nine months
- A Finalsite alternative for districts that mainly need websites
- White Label for Freelancers
- White Label for Hosting Providers
- White-Label Website Builder for MSPs & Agencies
- White Label for SaaS Platforms
We.Inc is an AI-powered website builder you can resell under your own brand. Launch a branded client dashboard, bill on Stripe Connect, and deliver AI-generated websites in minutes. White-label pricing is tailored to your volume and setup: book a 30-minute demo for a quote.
Product
- AI Website Builder: Describe a site in plain English; it's live in minutes
- White Label Platform: Your brand, your domain, your margin
- Enterprise: SSO, custom SLAs, and dedicated support
- Developer API: Embed site generation into your SaaS
Who It's For
- For Agencies: Resell under your brand
- For Freelancers: Your own branded builder
- For Hosting Providers: Add a builder to your stack
- For SaaS Platforms: Embed site creation via API
- For Startups
- For Financial Services
- For Healthcare
Features
- Drag & Drop Editor
- Built-in SEO Tools
- Custom Branding
- Client Dashboard
- Reseller Billing (Stripe Connect)
Resources
- Blog
- Help Center
- Free Business Tools
- Free UI Components
- Website Templates
- Template Collections
- Website Examples
- Guides
- Comparisons
- Alternatives
- Best Lists
- Reviews
- Pricing Guides
- Use Cases
- Glossary & Guides
- Integrations
- Developers
- Benchmark
- Windows App