Microsites and Organic Groups at Scale

We’ve developed a huge platform for over half a decade to host the official sites of the United Nations’ member countries, and we’ve never really posted about it. It’s 140 Microsites, built on top of a single code base and database. Having the word “Micro” before Microsites is really stretching the definition. There’s nothing micro about them. Head over to your favorite UN member country to see it in action. Here are a few completely random ones:

• Democratic People’s Republic of Korea
• People’s Democratic Republic of Algeria
• Republic of the Congo (Not to be confused with “Democratic Republic of the Congo”).

This post is a reflection of why we always try to avoid such architecture, and why we almost always still end up going with that level of effort; how much it should cost (less than having 140 independent sites); the common pitfalls we’ve gathered over the years (many).

What are Microsites

Microsites are sites that share the same structure and purpose, usually under one organization, but are meant to serve different branches, offices, or audiences. They can have their own content, languages, and editors, and sometimes even a different look. In a setup like the UN’s, each country office site is technically similar, but each is managed by a different local team, with its own priorities and style. They’re independent enough to feel separate, yet still connected through a shared foundation.

The term “microsite” is misleading. Once you have hundreds of them, each with custom permissions, content, and translations, there’s nothing “micro” left about it. It’s a big system pretending to be many small ones.

The Options - From Worse To Bad

None of these options are easy. Microsites are the kind of problem where every path feels wrong; you just choose which pain you can live with.

Drupal Core Multisite

Drupal core supports multisite out of the box - one codebase, multiple databases. Each site lives in its own folder, with its own settings.php and config. It sounds like the perfect middle ground, but it’s tricky. Since each site has its own database, sharing content or media between them isn’t easy. You end up duplicating content and maintaining it in multiple places.

It’s also easy to drift apart. One site might enable a module that another doesn’t. The codebase starts to fill with conditions and exceptions. Updates get risky, testing becomes inconsistent, and what was once a single system starts behaving like 140 snowflakes.

Many Independent Sites

You can skip multisite altogether and spin up fully separate sites, maybe from a shared installation profile or a “blessed repo.” Each one grows at its own pace with its own modules, DB, and deployments.

That freedom comes at a high price. Updates multiply, features need to be reimplemented, and infrastructure costs climb fast. It works when you have a few sites, and I guess one can pull it off. I have never had to deploy 140 sites at the same time, taking into account other services required to sync up with. I’m grateful for not having to do that.

Organic Groups (One Codebase, One Database)

This is the path we’ve taken: one database, one codebase, and all sites inside it using the good old Organic Groups (OG). Each group acts like its own mini-site, with its own editors, menus, and domains.

It doesn’t make life simple - nothing in this space does - but at least it’s all contained. One deployment, one update flow, one authentication system. When something breaks, it breaks once, and we fix it once. People often worry that “if one goes down, they all go down.” True, but the opposite scenario isn’t much better. If two independent sites go down, can your team really fix both in parallel? How about fifty sites in parallel? Centralization keeps the chaos in one place.

An Actual Budget

It’s not common for agencies to talk numbers publicly. Most hide behind “contact us for a quote.” Not in this case. Here’s what a typical microsite setup actually looks like. This is the type of functionality we usually include when setting up a new microsite under a large shared platform.

That’s already around 100 hours, not including project management and quality assurance time.

The advantage of this setup is that every feature is instantly shared across all microsites. Add a new layout component, fix an accessibility issue, or introduce a better search filter, and all microsites benefit immediately. In the real world, budgets aren’t equal. Some country offices have more resources than others. So it’s common for one site to fund a new feature or improvement, and for everyone else to benefit quietly later.

This is a key factor in businesses and NGOs: Different departments have separate budgets. Having this shared architecture, where each feature or fix benefits everyone, helps gain widespread support.

Common Pitfalls

After building and maintaining 140+ microsites, a few lessons have burned themselves into memory. Here are the main ones - the things that look small at first but grow teeth later.

Don’t Allow Too Much Customization

It’s true for every project, but microsites make it worse. The more freedom you give, the faster things get out of sync. Each exception doubles the effort. A feature that behaves slightly differently per site might sound harmless - until you have 20 variations of the same thing. Every feature should work across all groups. Design with a wide view: make it flexible, not unique. Simplicity scales.

Configuration Should Live in the Group Content

In our setup, the Microsite (e.g. a Country content type) is the source of truth. We use fields to control which features are enabled: news, events, search filters, etc. If a site doesn’t need something, it’s disabled at the microsite level. This keeps logic consistent and avoids hidden configuration surprises buried deep in forms or settings pages.

Uncompromising Automatic Tests for Access

Microsites multiply editors, roles, and permissions. That’s a recipe for mistakes. We run automated tests to ensure users only see what they should. Every developer aims to write at least one test daily, but when it comes to user access, the rule of thumb is to automatically test every edge case. Everyone sleeps better at night knowing those tests are in place.

Handle the “Unpublished Microsite” Case

It’s common to have a new microsite in development or to be working on new language translations. Editors should still be able to create and preview content even while the microsite itself is unpublished. Once the microsite is flipped to published, all its content should automatically go live. This avoids confusion and saves editors from having to recreate work.

Don’t Underestimate the Level of Support Needed

Launching the system is the easy part. What follows is the long, quiet grind of support. Each microsite has its own editors, questions, and small fires to put out. Multiply that by 140, and you start to see the real scope. Support isn’t just about fixing bugs; it’s about guiding, explaining workflows, and helping teams understand what they can and cannot change. Much of the initial support was handled by a skilled UN internal team, but if that’s not the case, expect to receive plenty of questions.

Demo

Grab the demo repo, and follow the installation notes.

https://github.com/Gizra/Microsites-Drupal-Starter

Slides