I've been asked recently [thanks to this post-https://civicrm.org/blog/jackrabbithanna/why-civicrm-long-term-support-lts-is-important ] about switching to the latest LTS, which is 4.6.37, from 4.7.29.

The first (and only) attempt fails right at the "your database doesn't seem to have civicrm_settings table" message.

So, any way to downgrade (or any arguments for not to?). It updates easily to the latest 5.2., but "LTS is LTS". Thanks!

  • what is the goal of downgrading? is it that you/they think 4.6.x will be more secure/stable than 4.7.x?
    – petednz - fuzion
    Jun 13 '18 at 22:56
  • 4
    I think you have misread the article. 4.6is only supported until the end of this year whereas 4.7 / 5.x are supported indefinitely at this stage (and certainly longer than the end of this year!). The article, I believe, trying to solicit funding to do a new LTS off 5.x Support for 4.6 means that any security fixes that are identified in the latest version of CiviCRM that ALSO exist in in 4.6 will be backported to 4.6. Security scanning is generally done against the latest version so where vulnerabilities exist in an older version but not in the latest version they may not be identified.
    – user4278
    Jun 14 '18 at 0:43
  • The reason I'm looking at the LTS is because it looks like a version which does not need to be upgraded as often. I do not need anymore features - I just want to keep what I have secure. When I read the article I thought it looked like that was what the LTS version was for. The upgrades often lead to little glitches which need to be fixed. Given that I don't need the new features I just wondered if I could have a more static version of civicrm which was secure. Any more thoughts welcome (I have definitely got that going backwards is not good idea - thank you everyone!)
    – Caroline B
    Jun 14 '18 at 9:20
  • @CarolineB how often do you currently upgrade? Unless there is a bug or feature that you need - I wouldn't upgrade unless there is a security update - which is usually once - maybe twice a year. LTS is really only for those that are not ready to (or can't) migrate to 4.7/5.x
    – themak
    Jun 14 '18 at 20:35
  • There is a trade off with upgrading less frequently - basically if you upgrade frequently & hit glitches they will get a rapid response when you log issues in gitlab. If you upgrade infrequently & hit glitches you may be on your own to resolve them. The logic here is that you are making a business decision. If you choose infrequent updates then you save money there but you may have other costs if things work differently. If you update more frequently that may cost you more but we will try to mitigate any other costs, as we acknowledge frequent upgrades mean quick issue identification
    – user4278
    Jun 18 '18 at 0:12

Is it possible? - Probably, with a lot of time and skill.

In most releases, there are changes to the database structure or table content determined by the files under CRM/Upgrade. To revert back to a previous version you could in principle work through all the updates between your current version and the one you want to go back to and reverse each change in your database. So if a table had a column added, you would need to remove it etc. If a column was dropped, you'll have a harder time adding it back as you may not have the right values.

A git diff to show the differences in CRM/Upgrade runs to nearly 10,000 lines (depending on what options you use), so you would have a lot to work through!

Upgrading is regarded as a one-way process. If you do have the time and skills to successfully revert, I'd suggest that is more beneficially put to use in fixing any issues you find in the latest release.


If you really - really - want to get to 4.6.x create a new instance and migrate your data from the 4.7.x to the 4.6.x as you would when coming from any other database/CRM;

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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