The CiviCRM project follows conventional terminology for software releases:

The core development team aggressively releases two to three major versions each year, and three to four minor revisions in between the major releases. The version number follows the conventional format as well: 3.2.4 = version 3.2, revision 4. You may track bugs and issues reported for a certain version through the CiviCRM website.

Since revisions typically correct bugs or address security issues, you should ideally implement them as soon as they are released. Revisions generally require minimal modifications to your database structure or data; so the potential risk of running into any issues is less.

Before conducting any revision upgrade, back up your database and file system and test to ensure the integrity of the backup files. It is particularly important to have a reliable backup of your database, as you will need to restore the database to the previous version should there be any problems during the database upgrade script. It is also recommended that you perform upgrades on a development server before implementing on your live server. We consider it essential to use a development or staging server for sites that have custom templates and code.

Finally, if you have made any modifications to CiviCRM files, including template (.tpl) and CSS files, be sure to have a good record of your changes. You will need to review the changes against the new codebase and may need to adjust them. This is particularly true for major version upgrades, as the files are more likely to have significant changes.

CiviCRM provides some helpful tools for maintaining custom development work:

If you are planning to move your website to a new hosting environment or from a development server to a live server, you will need to follow several steps in order to ensure that CiviCRM is configured properly in the new environment. The following content represents the key issues to consider and address when moving your site; a full discussion of steps to move a site can be found online: http://wiki.civicrm.org/confluence/display/CRMDOC/Moving+an+Existing+Installation+to+a+New+Server+or+Location.

After transferring your site's files and database to the new location, you must update several files to reflect the changes. CiviCRM references the root directory for your files and the full URL for the site in several locations. Follow these steps:

After completing the move, be sure to test the site! Click through CiviCRM and confirm that the pages load as expected, and the URL remains on your new site (if any outdated links exist, it may send you to your old domain or subdirectory).

As with any database system, there will be ongoing maintenance steps that should be performed on a periodic basis. Our focus in this section will be on basic maintenance steps specific to CiviCRM. It is outside the scope of this chapter to address the broader topic of server and MySQL database maintenance. Depending on the size of your database and whether you are using a managed hosting service, you should be aware of basic maintenance steps with your database and hosting environment. Also, we will not address scalability-related issues and maintenance. However, as your system grows, you should be aware of the impact on your MySQL database performance and size.

The most important maintenance step with your system is to keep it updated to the latest revision, and not fall too far behind in major version upgrades. As the steps for doing that have been addressed earlier in this chapter, we won't go into detail here; we repeat it only because of its importance:

Another important periodic maintenance step is dealing with duplicate contact records that have a sinister way of creeping into your system. This is particularly true if you have multiple forms collecting information from your public website such as event registrations and contribution forms.

Duplicate records usually result from existing contacts completing online forms using an alternative e-mail address or nickname. As a result of the alternate data, the record does not match the existing record, thus causing a duplicate.

Fortunately, CiviCRM has some excellent tools for deduping and merging your database, found under Contacts | Find and Merge Duplicate Contacts. The full range of these tools is detailed later in this book. For the purpose of maintenance considerations, you should schedule periodic deduplication of your entire database. Size and usage of your system will determine how frequently that maintenance should take place. After implementing your system, schedule an initial de-dupe/merge for one month from the go-live date. Depending on how many potential duplicates your dedupe rules uncover, you can schedule the next maintenance review accordingly.

When covering the initial system configuration, we walked through the creation of cron jobs on your server to trigger automated events and actions. In most cases, these will continue to operate without the need for any intervention or maintenance. However, it is a good idea to periodically check in order to ensure that they are, in fact, running properly and the scripts are completing. While creating the cron job, you may choose to have a log sent to an e-mail address. The log does not contain much by way of detail, but will provide a verification that the script has completed successfully. You should make a habit of periodically checking the configured e-mail to confirm that your scripts are running properly.

These basic maintenance steps should be all you need to keep your system running smoothly.

No chapter on maintenance would be complete without bringing up the topic of backup policies and procedures.

Regardless of where and how your contact database is being handled, it is pretty safe to say that the data stored in it is critical to the overall success of your organization and should be backed up regularly.

That consideration does not change just because your contact database now resides online. While you may have previously been content relying on the standard backup policies of your hosting provider for your website, the inclusion of CiviCRM as part of your website should now warrant a more robust plan and additional backup mechanisms to ensure your data is preserved and protected.

It is impossible to create a universal backup policy for all organizations. The traffic and usage of the system, nature of the organization, type of data you are maintaining, level of risk exposure, and other factors will all dictate what type of policy you should put in place. If you are uncertain what you should do, consider hiring an outside consultant to do a system and organization analysis for the purpose of developing a backup policy and procedure statement.

However, there are some universal rules and principles to consider:

Use these basic rules and invest your time and resources to ensure that your data is preserved in the case of accidental loss.