We are running an outdated version of Civicrm (4.2.7) on Drupal 7 and working on upgrading to the newest version of Civi, 4.6x. We have been quoted a full forty hours by a consulting company for the completion of the project, but as the database is designed to be upgraded, this seems excessive.

If you have experience in upgrades and could offer thoughts on how long it should take as well as likelihood of errors, it will greatly help our planning. We have some custom fields, including some forms directly linked with our website, but not an excessive amount.


4 Answers 4


Based only what you have said so far 40 hours is excessive and 4 hours is more reasonable. But some further discovery or prior knowledge of the kind of customizations you have in your site might make 40 hours a reasonable quote. For example, needing to upgrade a few extensions so they are available for 4.6 and do some advanced theming might require 40 hours.

Our upgrade process involves:

  1. Reviewing the standard native CiviCRM extensions and CMS modules/plugins used and ensuring they are available for the new CiviCRM version,
  2. Finding and analyzing the native CiviCRM extension built just for the site as well as the custom CMS modules/plugins developed just for the site - they may need adjustment, perhaps significant,
  3. Reviewing whether there is custom code and / or templates overriding CiviCRM or even using jQuery to adjust the DOM - this is often where some developer time is required during an upgrade,
  4. Reviewing the theme for CiviCRM customizations and noting they will need to be checked post-upgrade - the more extensive the more risk of breakage during the upgrade,
  5. On Drupal sites, checking for tweaks and customizations within the views using CiviCRM, or any non-views blocks etc that pull in CiviCRM data,
  6. On multilingual or non-English sites, checking for the availability of translations for CiviCRM, native extensions, and CMs modules/plugins,
  7. On a complex upgrade this is where we would provide the scope and estimate to the client.

In terms of the actual upgrade process, it involves:

  1. Backing up the site and restoring it locally,
  2. Running the upgrade process,
  3. Addressing issues identified in 1 to 6 above,
  4. QA of result,
  5. Usually deploying site to staging for signoff by other JMA staff and client (skipped for simple upgrades)
  6. After signoff, upgrading production site, usually by taking it offline during night in primary site timezones, doing the upgrade, deploying the changes from 9 to 11 above, and putting it back online.

To summarize the factors affecting the cost of upgrades:

  1. In browser CiviCRM configuration changes like creating custom fields and profiles don't require extra work to upgrade.
  2. More references to pages in CiviCRM from the CMS don't create extra work on upgrades.
  3. The use of each additional native extension from the CiviCRM extensions directory and standard downloaded CMS module/plugin that interacts with CiviCRM slightly increases the risk of extra work.
  4. The more code in extensions, modules/plugins, themes and especially custom PHP and Smarty template override files developed just for this site the more likely that developer time will be needed, and that more of it will be needed.

First question is what version of CiviCRM you are actually running, I understand your Drupal version is 4.2.7. Or is your CiviCRM version 4.2.7? If the latter is the case I do not think this is terribly outdated :-)

A standard upgrade of a standard CiviCRM install without any customization should not take that much, we would estimate that we normally assume an average of 4 hours. Without customization we do not often run into errors. In a quote we would probably say that we would need between 2-8 hours and we would bill the actual hours spent.

If you do have customization it really depends on how much customization you have, if it was developed in a structured way following community guidelines etc. In those cases we will probably say we want to take a look before we can give a quote. Also, the risk of errors occuring would be far greater than.

Does this help?

  • This does help, thanks! We are on Drupal Core 7.19 with CiviCRM version 4.2.7. We want to be on CiviCRM 4.6x. We have some customization, including some links to our website, but not an enormous amount of custom fields.
    – Gillian R
    May 12, 2015 at 12:21
  • Note that many a times providers discover customizations / modifications to the code / db which in general results in a longer time to sort thru, understand and fix. This might be one reason for the higher quote. May 12, 2015 at 14:15
  • The time required is not necessarily determined by the amount of custom fields, but more by the complexity of the customizations. Are your customizations in on or more civicrm extension(s)? May 12, 2015 at 14:37
  • I've spent 20 hours on an upgrade and 1 hour. If you have custom template/php files they all need to be retrofitted and that can take a lot of time. If this is an estimate and not a quote then you probably have some padding. You should definitely ask your consultant to justify 40 hours though. May 13, 2015 at 3:36
  • @Sonicthoughts I think this would be good as an answer rather than a comment.
    – Coleman
    May 22, 2015 at 1:36

There are really two parts to this process, and your consultant may be combining them into a single step.

The upgrade itself (making backups, downloading code, running the script) can be quick ... or if your installation is not standard and someone has been mucking around in the database, this can suddenly balloon from minutes to hours. This technical portion might take as little as 20 minutes on one of my sites, but I recently moved one client from 4.2.6 to 4.5.8 and problems with the database made that a 5 hour project.

After the upgrade is applied, there is testing. How much testing depends on how many features you use and how many customizations you have in place. If you have any custom templates or php code, each and every screen needs to be tested - and that time can add up very quickly.

Thus forty hours seems like a lot, but it might be justified.


4.2 is not heinously old - but the older the DB the more risk of something that won't upgrade smoothly. I have hit databases where they describe an error on upgrade but once I look at it I discover the whole database has at some point in the past been converted to myIsam engine and requires serious recovery.

I would be nervous about saying I could upgrade an unknown database in 4 hours as sometimes just getting the right site access can take that long!

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.