A service my company offers is similar to managed hosting where we help keep a server, Drupal, related modules, and backups up to date on behalf of clients who can't or don't want to do that in house, and typically this averages out to be about 30 to 90 min of work per site per month.

A client has asked me to manage their entire portfolio of 70 Drupal sites, all of which are part of a multisite architecture with site files on one server and DB on another.

I can't imagine that this is 70 hours of work, but I'm not familiar enough with multisite installs of this size to understand fully what this would entail.

To ensure that I estimate time correctly, what would I need to take into consideration when comparing management solutions for single server / single site installations as compared to the same number of sites in a multisite installation?

  • As a small hint about keeping modules up-to-date you can use some common services, e.g. drop-guard.net. They are doing all the updates. But I do not know if they are working with multisiting, you can ask.
    – milkovsky
    Commented Apr 5, 2016 at 9:47
  • 1
    It's really difficult to answer this, as keeping something up to date can mean a lot of things. The main difference between multi site setup and non multisite setup, is that they share code, which means you probably can deploy a lot / all of the sites with a single script. If the sites a very different and you have to test that updates wont break anything etc, it wont matter much that they are multi sites. If the site are near identical you can potentially save a lot of time.
    – googletorp
    Commented Apr 5, 2016 at 16:44

3 Answers 3


Short: It really depends.

Long: Each individual multisite installation adds complexity to the whole. If these 70 sites are more ore less the same in terms of individual content but (nearly) same codebase, modules and similar themes (imagine a large organization spread over the world with region specific characteristics), you'll most likely need less time to maintain.

If these are 70 profoundly individual sites, you'll probably end up checking dependencies over dependencies for modules and themes, debugging deadlocks and incompatabilities. Maintaining this can be a real challenge and 70 hours a month are gone faster than you have "drushed and rollbacked" everything to working.

Accurate documentation and a SLA designed fair for both parties should be the key to a successful maintenance.

(I maintain a multisite installation with around 30 instances for a large organization with all the pros described above.)

  • Would you mind sharing about how long maintaining 30 takes you and example tasks you spend that time on? (If commenting publicly about that info would be ok, that is.) An experience like yours is exactly what I'd like to draw from.
    – blue928
    Commented Mar 29, 2016 at 20:16
  • I can't share numbers, but gut feeling says it's about a third of the time compared to single installations when it comes to keeping modules and core up to date. The most time-consuming tasks are the feature-requests from single divisions. We process all this with a ticketing system and a good SLA. As you can imagine a global organization tends to spread in different directions, both form and content-wise. So keeping everything in line is the real challenge (thank god there's a marketing office with the last word).
    – Volker
    Commented Mar 29, 2016 at 20:38

Maybe you should include Aegir in management. Aegir, along with Drush, can help you a lot to automate some tasks, from backups, verification, enabling / disabling SSL, adding new or removing existing platforms and their multisites.


I can say that you should take into consideration that managing multisite drupal installation usually takes less time then handling same amount of single installations. I will briefly explain how it can be done for drupal 7

1) when you download drupal you can find sites folder in root;

2) You can add as many websites as needed inside sites folder, just create for example "example" folder;

3) In example folder create settings.php file

$databases['default']['default'] = array (
  'database' => 'example',
  'username' => 'admin',
  'password' => 'admin123,
  'host' => 'db_host_address',
  'driver' => 'mysql',

4) create modules, themes, libraries folder for site specific modules, themes and libraries in sites/example folder. All common (used by more then one site or features which potentially can be used in future by multiple sites) modules, themes, libraries can be added into corresponding folders inside sites/all directory.

5) To establish http connection with example website you should create server alias then add sites.php file inside sites folder.

$sites['localhost.example'] = 'example';

where localhost.example is your server alias and example is your site folder.

you should take into account that in future it will be easier to update drupal core and contributed modules but as cons you should take into account that during each common change all websites which use changed module, theme should be tested well. In case of updating core all sites should go through round of testing.

From my personal experience multisite installation is easier to maintain. I wish you good look with your task!

Not the answer you're looking for? Browse other questions tagged or ask your own question.