Separate sites for CiviCRM and public site?

Question

Is there a best practice as to whether CiviCRM should be installed on its own site, separate from the public site or as part of the public site?

I think of our internal users doing mailings etc and it doesn’t “feel right” for them to do this on the CMS for our public-facing site, but at the same time we want to allow self-service contributions and event registrations.

Is there any issue to link across sites (for example link public site to membership form served on CiviCRM)? Or is that just a pain.

I’m afraid to just go ahead and install CiviCRM on our production public site. We use WP fwiw.

Appreciate any advice.

Answer 1

I have a number of clients who use CiviCRM on a subdomain separately from their main content site. It has both pros and cons.

Pros:

1. Security.

The main issue addresssed here is the risk of security lapses on the main site exposing CiviCRM. The reason a separate site can be more secure is that you will typically have more modules and functionality on your main site where ease of use is the primary goal, whereas with CiviCRM, security is a much higher priority. Keeping the CiviCRM site with fewer 'ease of use' tools and generally fewer functions will almost always make it more secure, at least in principle.

Analogously - you can also provide hassle-free administrative access to designers and content editors without risk of inadvertently exposing CiviCRM.

2. Performance.

The primary use case of your main site will typically be anonymous access by visitors, whereas most of your access to CiviCRM will be authenticated. The kind of server setup for those two types of access are frequently at odds, so having them on separate servers can make for better use of machine resources. e.g. you can put your main site on a relatively inexpensive hosting service with heavy caching for anonymous visitors.

Cons:

1. Expertise

Keeping internal resources to understand how multiple systems works can be a hassle and/or expensive. This is really the key driver of the decision - if you already have reasons to keep your CMS where it is, or to move it to a different CMS than your CiviCRM is on, then a split install is often a good choice.

2. Maintenance

The main other cost of the separate installs is maintenance - keeping up two sites instead of one, and updating design elements to keep the visual link between them convincing.

3. Server costs.

Usually, two sites is going to cost more than one, but see note 2. above. Specifically - by having the lower-security functionality all together, you can use your budget more effectively, e.g. you can have a managed CiviCRM install and use more off-the-shelf (read cheap/do-it-yourself) tools for your CMS.

I would also note that you don't need fancy machine-level integration as suggested by ErikH - you just need links back and forth, and an internal clarity that the two pieces are only loosely joined.

For clients who are migrating from other solutions (e.g. separate online processsor services, mailing lists and event services), putting all these together on one CiviCRM site that they manage is already a huge step forward in integrating those pieces, and having that functionality relatively loosely linked to the content site is not usually a show stopper, and in some cases a desirable state.

Examples

Here are few sites that are hosting CiviCRM on a separate subsite:

1. https://www.awid.org/
2. https://www.wildernesscommittee.org/
3. http://www.fairvote.ca/
4. http://www.patientscanada.ca/
5. http://everdale.org/
6. https://wildsight.ca/
7. https://www.bcndp.ca/
8. https://www.kairoscanada.org/

Answer 2

It depends on your security and privacy requirements. I agree with Pete that for CiviCRM to work most simply, install it on your public facing CMS.

You should realize however, that from a security and privacy viewpoint this is not the most secure option. If that is important to you, you should install CiviCRM on a separate server. However, that does mean that you have to think a little on the communication between your public website and CiviCRM. You can use the REST API to communicate with the CiviCRM server from your public website but is does mean you have to do some coding in your website forms. Again, it depends on your requirements.

Hope this helps!

Answer 3

We have several clients with a WordPress public site and a Drupal based CiviCRM. to keep their hardworking nonprofit website staff happy.

If your website team insists on Wordpress and you need to take advantage of more advanced features of Drupal for things like portals and more complex integrations it can be a good compromise.

Answer 4

For civicrm to work best/most simply, install it on your public facing CMS.