Upgrade Your SugarCRM System Before it Gets too Expensive to Upgrade

by Eric Wikman on May 10, 2009

The majority of W-Systems' clients are currently running SugarCRM 5.1c with a few (including W-Systems) that have opted to upgrade to 5.2. But a couple of our clients are still on the old SugarCRM 4.5.1 architecture. Within a couple of months, I expect that all of our clients on 5.1c will have migrated to 5.2 (we usually don't push a new point release until a couple patches have come out unless there is a critical bug fix in a new version that our clients need). But sometimes we run across companies running much older versions of SugarCRM. I'm always surprised to see that they have not kept up with upgrades and new releases. I've found that companies typically give one of five different reasons for not wanting to upgrade:

  1. They have too many code customizations in their CRM system that might have to be fixed if they upgrade.
  2. They had a bad experience with an upgrade in the past.
  3. They don't want users to be unproductive while they learn how things have changed in the new version.
  4. They don't know if the new version is stable and are concerned that it will have bugs.
  5. They can't justify the time and expense to actually perform the upgrade.

Let's look at each of these issues and figure out how to upgrade safely, smoothly, and efficiently despite the potential risks.

Code Customization

If code customizations have been done improperly then the first reason is significant and might be a valid reason for planning carefully before performing an upgrade. This is why we deploy only upgrade-safe customizations when we modify a client's system. Poorly written customizations may very well need to be rewritten before an upgrade will succeed. But this is almost always worth the time and trouble because it reduces future support risks and opens the way to taking advantage of new features offered in new versions. Depending on your current release, security patches or major bug fixes that cannot be deployed because of poor customizations should be addressed immediately, even if a version upgrade is not planned.

Bad Upgrade Experience

Bad upgrade experiences are usually the result of poor planning or not following upgrade best practices. SugarCRM upgrade processes can be very complex and there are many opportunities for failure. It is imperative to make a full system (code and database) backup before an upgrade is made and to test the upgrade in a development environment before performing it on the production system. W-Systems has performed so many customer upgrades that we have it down to a science. Just because you have had a bad experience in the past is not a good reason to resist upgrading. You just need the right plan and the right people performing the work. We can help you with that.

Lost Productivity

Training in advance of a major upgrade can mitigate lost productivity as users move from one version of software to another. We design and deliver training packages that can be tailored to your users' specific needs. These can be delivered in person, via live web conference, or as a package of web-based screencasts. Keep in mind that new versions often offer new tools that will actually make your users more productive than they were before.

New Version Stability

SugarCRM is a powerful and complex enterprise-grade software application. Like all other software of similar complexity, there will be bugs in new releases. The key to avoiding potential bug problems is to work with a partner that you know and can trust to monitor new releases and notify you when it is safe to upgrade. Some of our clients are operating on the bleeding edge and like to deploy new releases as soon as they are available, understanding that bugs might still exist. Others prefer to wait until a new release has been tested in the field to make sure there are no service-affecting problems. There is no set rule for when to upgrade, but W-Systems tests and monitors the progress of bugs and their resolutions and makes a judgment call when we think the main issues have been resolved. We can often implement a hot-fix if a client upgrades early and then runs into an issue. By working with us you can also be sure that we will contact you immediately if there is a security update released for the version you are on. We keep track of what each of our clients is currently running and are very proactive in announcing security updates.

Upgrade Time and Expense

I firmly believe that the longer you wait to upgrade, the more expensive it becomes. Let's take a look at a project we recently completed at W-Systems as an example. A new client recently approached us to upgrade their system that was running SugarSuite version 3.5.1. Since our clients are kept up to date on their releases I was a little surprised that people still are running version 3. I did some Google research based on search volume for different versions of SugarCRM in the first half of 2008 and found the following:

  • 1.44% of users are still on Sugar 3.x
  • 36.08% of users are still on Sugar 4.x
  • 62.48% of users are currently on Sugar 5.x

The danger of staying on an old version for an extended amount of time (besides the lack of support and possible security issues) is that it becomes complicated to upgrade to the latest version because of different prerequisites for different versions of Sugar. Chances are that if you are on version 3 of Sugar your server is running very old versions of MySQL and PHP. It is quite possible that your server is not properly patched for security issues with the OS and applications like the web server, MySQL and PHP. You can't upgrade Sugar 3 to Sugar 5.2 directly, you must go through a series of upgrades to accomplish this. Clint Oram (the co-founder of SugarCRM) keeps track of the various upgrade paths to get from an old version to the current version. To move from SugarCRM v3.0 to v5.2 (as our client wished to do) the following path had to be made:

  • v3 upgraded to v3.5.1
  • v3.5.1 upgraded to v4.0.1
  • v4.0.1 upgraded to v4.5.0
  • v4.5.0 upgraded to v4.5.1
  • v4.5.1 upgraded to v5.1.0
  • v5.1.0 upgraded to v.5.2.0

So customers really don't save much money by not upgrading when a new version comes out because they still have to make most of these upgrades, and in the meantime they haven't taken advantage of the incremental improvements in Sugar that could have increased user productivity and expanded the types of things that could have been achieved with Sugar.

But the problem is actually much worse than that, because some versions of Sugar require different pre-requisites (Apache, MySQL, PHP) than other versions, and some are completely incompatible with others. So if you are not on version 4.5.1 or better right now, then your upgrade path will include upgrading lots of software, not just SugarCRM.

For instance, to upgrade from Sugar 3.5.1 to 4.0.1 you need to be on a server that does not have MySQL 5 or PHP 5. Old versions of Sugar had some field names that later became reserved words in MySQL 5, and they also had a class name that clashes with a class name in PHP 5.2.

In the case of our client running 3.5.1, we had to use the client's server to upgrade to 4.0.1 because it had old versions of MySQL and PHP that were compatible with 3.5.1 and 4.0.1. But once we upgraded to 4.0.1 we couldn't use the same server to upgrade to v4.5.0 because v4.5.0 required MySQL 4.1.2 or newer, but not PHP 5.2 or greater (are you confused yet?). This server had MySQL 4.0.23. So we had to set up a separate server that had MySQL 4.1.2 and PHP 5.1.6 to upgrade from v4.0.1 to 4.5.0. Then we used that same server to upgrade from v4.5.0 to v4.5.1 (since v4.5.0 still can't run on PHP 5.2). To upgrade from v4.5.1 to v5.1.0, we once again had to move their installation to a server that was running MySQL 5 and PHP 5.2. Technically SugarCRM v5.x still works with MySQL 4.1.2 and PHP 5.1.6, but we didn't want to leave this client running on a server that is already out of date. Confusing, isn't it?

It was difficult and time consuming (not to mention expensive) to track down old versions of MySQL and PHP, install and configure them, and then move the customer's CRM system from server to server during different phases of the upgrade.

We used CentOS 5.2 for this upgrade because it still uses PHP 5.1.6, so it was easy to get a server setup with the proper binaries for MySQL and PHP. But what really saved the customer time and money was W-Systems' virtual servers. By using virtual servers we are able to install and configure a new OS in a matter of minutes. Without virtual servers, we would have been forced to find old hardware to install the various OS and LAMP components necessary for each upgrade step. This would have taken many, many more hours.

So if you put off upgrading too long, it will be a lot more difficult to get a server setup with the old versions of PHP and MySQL necessary to run the upgrades. Right now you can still find old Linux distributions with active repositories of versions of PHP and MySQL that will work, but these are becoming increasingly difficult to find.

It is also important to remember that SugarCRM no longer supports many old versions of Sugar. So if a security hole is found in an old release, it won't be patched and you will be vulnerable. Here are the current end-of-support dates for older versions of SugarCRM:

  • SugarCRM v4.2.1 and all older versions were retired on or before November 30th of 2008
  • SugarCRM v4.5.0 is being retired on February 28th, 2009

Although a retirement date has not been announced for SugarCRM v4.5.1 we are encouraging all of our clients to migrate to 5.1+ by the end of October 2009 (including people on v5.0).

Is it time for you to upgrade an old system? Contact us and we'll help you develop a migration plan.

Find similar articles in these categories:

PRODUCT: SugarCRM

AUDIENCES: End Users Administrators