With my blog, I use it as my release candidate before rolling out to my clients.  I have a few followers, so it keeps me in production mode.  With my blog on the bleeding edge of BE.N builds, it keeps me connected to the community. 

I'm working on a Standard Operating Procedure (SOP) for updating sites.  There has been some discussion on BE.N forums of supporting multiple blogs using single code instance. 

Here are my requirements:

• Support multiple URLs
• Support multiple subdomains
• Each site has individual folder for data (for sites using XML storage)
• Each site has individual tables (SQL Server sites, my clients don't want to mix their data)

Currently, here are my steps for updating clients:

1. Notify clients
2. Download BE.N build
3. Add in custom widgets, user controls, controls, and extensions (all clients get everything, enable/disable per client)
4. Add in custom themes (all clients get everything)
5. Update Resource files (again all clients get everything)
6. Using VS.Net, publish BE.N to a folder (engine is consistent for all clients)
7. For each client, cloan the published folder
8. For each client, sync storage (App_data) or SQL Server content locally
9. Test each client locally
10. Backup all clients
11. Push new build for each client ( don't push storage/SQL Server - don't want to overright content)
12. Post deployment testing for each client
13. Notify clients

As you can see, there is effort to update all clients.  The biggest time saver is to use controls/extensions and don't modify the BE.N engine.  Create a consistent build for all clients.  Most of the work is making sure build works with all clients content. 

If BE.N could host multiple clients on one build, I would save time on step 7, 11, and 12.  What are your thoughts and would the architecture below be possible?  One copy of the engine supporting multiple clients?