I'm being forced to break up one CiviCRM (in Drupal) database into several separate ones, and it seems that using subdomains would be the most elegant way to do so. That is to say I would copy website.com to one.website.com, two.website.com, and three.website.com. Then I'd change the base URL and have them exist separately from thereon. They would not share the same Drupal frontends either.

My questions are these: Would I face any unforeseen consequences in doing so? Can these installations exist side-by-side in harmony? Would my SMTP service (CiviSMTP, in my case) throw a fit? Is there a smarter way to go about this?

2 Answers 2


I have done 1 CiviCRM per subdomain in a big project. About 20 separate subdomains with their own CiviCRM.

If settings are all correct then there is no side effect. They all just work. With copying a CiviCRM to another Drupal instance (subdomain or not), you need to think about

  • the connection between Drupal users and CiviCRM contacts
  • the CiviCRM table settings in settings.php
  • the user uploaded files, you probably want to copy all to 2nd CRM

Those subdomain Civis all handle their own SMTP. No issue there either.

I don't know CiviSMTP, maybe you need an account per subdomain, maybe they can share the account.

  • I did go ahead with this plan. Eight subdomains working perfectly and 100% separate. All subdomains were able to maintain use of one CiviSMTP account.
    – Eric H
    Commented Mar 23, 2016 at 21:41

There are a few different ideas in your questions that mix different approaches. Multiple sites, multiple databases, multiple domains, multiple internet subdomains.

You can create copies of website.com at one.website.com, two.website.com, etc. in a few ways in Drupal. Focussing on the files, you can 1) copy everything under docroot to a new docroot for each site and configure webserver (Apache, nginx) to serve each subdomain from the appropriate docroot, or 2) create a new directory under sites for each subdomain eg sites/one.website.com, sites/two.website.com, etc. with all subdomains being served from same docroot by webserver. If you expect the sites to diverge significantly and/or need upgrading at different times that tends towards approach 1, while staying the same or similar in the future and having simultaneous upgrades tends towards approach 2.

I'm assuming you're going to have separate Drupal databases for each subdomain site.

You have the option of also replicating the existing CiviCRM database for each new subdomain site or using CiviCRM's multi-domain features to manage all of the sites from within the same database. Eileen and Chris at Fuzion are the experts in the latter approach, which they have used successfully for many years. The advantage of this second approach is that you can manage CiviCRM upgrades to all sites simultaneously. Some tables in CiviCRM have a domain field, which would need to be set to different values for each subdomain as you replicate the data in the same database for each subdomain's site. This will be more complicated to convert to than separate CiviCRM databases for each subdomain, as the latter can be simple copies of the existing site.

In either approach, follow the instructions at http://wiki.civicrm.org/confluence/display/CRMDOC/Moving+an+Existing+Installation+to+a+New+Server+or+Location for each new subdomain, since more things than just the baseurl need to be modified.

An additional essential point when replicating a site is to ensure that the bounce processing and email-to-activity email accounts are different for each site. Certain extensions may also need to be reconfigured on a per subdomain basis; for example, the webhook url for Mandrill callbacks will need to be updated properly. I don't recall CiviSMTP doing callbacks in addition to email routing for bounce processing, so you're likely fine without doing any more work.

Other than rejigging the inbound email accounts and inbound webhook urls, I don't see any problems with running the sites side by side.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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