Best Practices for Managing Client Customization Requests In A Multi-Site Setup

Drupal's multi-site feature makes it possible to significantly increase the efficiency of managing a group of similar sites.  Imagine you have a group of clients where each client owns a site within your multi-site structure.  Undoubtedly, many of them will want to take advantage of Drupal's ability to add new features, which makes sense.  But if you're not careful, you can find yourself in a nightmare situation caused by a perfectly reasonable business decision to implement what clients want, when they want it.  The purpose of this blog entry is to provide some best practices that will make managing this kind of system a rewarding experience for you and your clients:

1. Prohibit Site-Specific Functionality:
One of the biggest advantages to using multi-site is that an arbitrary number of sites can use the same code.  This means if a bug is discovered on one site then it can easily be fixed across all sites.  So, whether there are five sites or fifty, the cost of adding new features and fixing bugs is about the same. 

Avoid breaking this rule at all costs; if you have to do it, copy the site in question completely out of the multi-site system and then make changes.  Ideally, you would eventually integrate this one-off site back into the herd, along with it's custom functionality.

2. Make Use of a Development Cycle:
Your clients are going to want new features.  When a request for site-specific customization comes in, during deployment of a new site or later on, resist the temptation to implement it immediately, even if it is simple. Instead, save it for later in a prioritized queue of feature requests.  Once the current version of the code is stable and bug-free, you can start working on the next version. Your clients may not like this because it means they will have to wait longer for new features, but the end result is that they will get more features sooner.  Also, any bugs that are found can be fixed faster since developers won't have to account for a laundry list of site-specific code.  It may be helpful to consider what you're offering to be a product with a version and a concrete set of features rather than a highly customizable service.

3. Make Theme Customization an Up-Sell:
I would suggest you set up a template site with a default theme that allows color customization.  Depending on the services your sites will provide, some of your clients may be satisfied with your default theme.  For clients who need to customize their theme, charge more money because this introduces a measure of complexity to the system; the more changes you make to a given site's theme, the greater the chance that something may work incorrectly.  These pricing options help encourage clients to opt for a more standardized theme.

4. Limit Site-Specific Admin Role Functionality:
Set up a site-specific admin role with permissions that don't allow clients to add new features and absolutely never give them access to the "PHP code" input format.   If clients have full admin access to their sites then, worst case, the security of all of your sites could be compromised.  Although that probably won't happen, if a client implements new functionality that causes problems then the resultant business need to fix it may force you to hack the code for all sites to satisfy a single client's immediate needs.  This situation is a good example of what needs to be avoided.

5. Never Give Clients Server Access:
If one client has access and breaks something then all sites could be compromised.  If clients want to submit code then accept it and treat it like a feature request.