SugarCRM Script Installer Upgrade Process Breaks Installs

The SugarCRM upgrade chain is complex. Sometimes there is not an obvious upgrade from the current version to the new version.

The checker correctly detected the avail of Sugar Community Edition 5.5 and 5.5a, but the upgrades have gone badly.

The issue is that there are frequently upgrades to the database, so the upgrade script needs to be run.

When the upgrade script with the SQL is not run, errors like :"Sugar CRM 5.5.0a Files May Only Be Used With A Sugar CRM 5.5.0a Database." result.



Right now, at, there appears to be no patch between 5.2 and 5.5. There is a patch from 5.2 to 5.51RC3. Most people wouldn't want to mass upgrade to an RC3.

I have done a series of upgrades using the SI, but now have this situation where I have 5.5 code, but a 5.2 (apparently), datatbase.

For most of these, I guess there were no database changes, so I was able to just edit the config table in the database with the new version information, and Sugar started working again.

There's a thread at , which specifically mentions that this trick will not work when there are structural changes in the db.

That thread also says that the correct way to upgrade is to use the integrated upgrade facility in Sugar, which obviates some of the benefit of using the SI for management, in that the domain owner still needs to do something. But, unless there are security fixes, this may be for the best. Except, in this case, the desired 5.2 to 5.5 patch did not appear to be available on the download page.

Messy....It may be that Feature in the Script Installer which installs the new version fresh, but then imports the old data would work in some cases?

Odd, I didn't noticed this on my test systems .. but maybe that's because I just did the upgrades one version at a time.

Is there no page within the SugarCRM UI that can do the DB conversion? Most apps Virtualmin installs will do this automatically when you login after an upgrade ..

The 5.5.0 to 5.5.0a upgrade is a good example. I just hosed a working install by trying this through Virtualmin.

Undoubtedly, the correct way to do these upgrades is via the upgrade patch manager in the Admin interface.

However, this nullifies some of the benefit of mass manageability.

Jamie, maybe you can some how figure out what the difference is between the regular installers (inital, Full version), and the patches, and come up with a way to make it automatable.

It occurs to me that there is a useful feature addition to the SI functionality, something like "prohibited transitions", reminiscent of the "Can't install Joomla 1.5 over top of Joomla 1.0" prohibited transition, a status of "requires manual intervention", something like that.

Otherwise, it seems to me that the Sugar Patches always have something indicative in their name, maybe even "Patch", I don't recall. If there is a Patch file for a certain version pair, it becomes a "prohibited transition" until some automatable workaround can be found. Make sense?

Damn, you're right .. this must have been a recent change, as I've done many upgrades via Virtualmin and not seen this before. I will fix the installer to block upgrades that would break SugarCRM, and to properly detect manual upgrades.

Does SugarCRM offer any kind of command-line method to upgrade the DB, or perhaps SQL file that can be run? That way I could have Virtualmin do it properly.

I don't know, Jamie. The manual update process within the application is top-notch, seems to do a lot of checks, and I have done dozens of upgrades, and never had a failure.

However, remember that Sugar actually doesn't want to make it "too" easy to to mass upgrades, because they SELL a Data Center Edition to their Partners. I've been to SugarCon twice, and they were really pushing that feature at the 2009 event. Anyway, the Patch .zip must have some PHP script, or else there is an upgrader PHP script within Sugar which interacts with the contents of the .zip file.

There is a stage in the upgrade process where if there are SQL changes you can toggle to select "Installer upgrades SQL" or "Manually upgrade SQL", or similar words, so the SQL must be in the .zip

Another factor is that maybe we don't really want to do mass upgrades, because people may have added extensions to their Sugar, which could be broken by an upgrade, not likely, but possible.

See if you can easily decipher their upgrade process, otherwise, we may have to dig deeper.

I am not aware of any command line options for upgrades, because it seems to me that would compete with their Data Center product.

I suppose all I could possibly do is have Virtualmin walk through their upgrade wizard, but that would be really tricky to script :-(

Or parse the upgrade file, and find the SQL and the files, and apply each...

I think that my couple of ideas are basically recognize and inform that there is a new version available, but in this case, 5.5 to 5.5a, for example, is a PATCH, which means that it has to be applied manually.

There are also "Silent Upgrades", and when those are offered, those should work using your Script Installer, I bet...I have never used them.

It looks like the current Silent Upgrade covers a wide range of existing versions, and there is a line in the ReadMe which says "Upgrade from Sugar Instances : 5.2.0x and 5.5.0".

You can see the Silent Upgrade in the list format that you'll probably need to trap somehow at

If this is too complicated, I would suggest you mod the Script Installer to ask for an Admin contact, but only during interactive install. IOW, don't alert the Host, alert the Sugar Admin that a new version is available, and requires manual intervention.

Hope this helps. Ken

Ok, perhaps it makes more sense for Virtualmin to show the possibility of an upgrade, but to inform the user that it must be done within SugarCRM.

Is there any way to know what upgrades are required to be done within SugarCRM via a patch file, and which Virtualmin can do?

Ok, perhaps it makes more sense for Virtualmin to show the possibility of an upgrade, but to inform the user that it must be done within SugarCRM.

Is there any way to know what upgrades are required to be done within SugarCRM via a patch file, and which Virtualmin can do?

Ok, perhaps it makes more sense for Virtualmin to show the possibility of an upgrade, but to inform the user that it must be done within SugarCRM.

Is there any way to know what upgrades are required to be done within SugarCRM via a patch file, and which Virtualmin can do?

My best figuring is that:

If there is a Silent Upgrade for the transition in question (which I have pointed out, the allowed transitions are covered in the .txt file within the THEN, you should run the silent upgrade (or offer to do so).

The above seems like the most general solution, and most amenable to automation.

If there is only an Upgrade, then those upgrades give the transitions which they cover as part of their filename. If there is no "SilentUpgrade" which covers the intended transition (current version-> latest), then just inform somehow of the availability. This is the case where you would inform the domain owner, not the Host, because the host presumably is not the SugarCRM administrator.

BTW, other things to note...5.5.1 just transitioned to GA from RC. You might offer RCs somehow. SugarCRM is a professional company with something like 40 developers, this is not a guy hacking in his bedroom after his real job, so the RCs are likely valuable.

Go ahead and try to implement this...I have a bunch of dead in the water 5.5 installations I could test against, or deploy new.

Ok, thanks .. I will do some more research and monitor new Sugar versions, and see how Virtualmin can automate the upgrade process. I may have to end up adding rules on a version-by-version basis to encode what is allowed.

For the near-term, I will have to make Virtualmin force the user to upgrade manually from within SugarCRM - but it will detect and show versions upgraded in this way.

Very good Jamie.

It may be helpful to you to know that there is an About type link in the Sugar Admin which returns the version number, and you likely know where that number comes from, but AFAIK, it's both in the config(uration?).php and in the config table in the database.

Looking forward to moving this forward.

I think it's a good opp. to incrementally beef up the internals and capability of the Script Installer to handle more "Enterprise" scripts.

Thanks for caring about this.

Best, Ken

Virtualmin currently gets the actual version of a SugarCRM install from the sugar_version.php file..

Interesting. I just checked, and it's in my config.php in the sugar root, and I know that the database version is in the config table in the database. That seems a little bit precarious to my untrained eye. I would think it ideal to have it defined only once, but I am no expert.

I was just trying to give you more options for checking the version number, because more options seems better. I would bet that these numbers update at different parts of the upgrade cycle, so it's likely that they are out of sync at least momentarily, during upgrades.


It's probably no news, but I was in the middle of an upgrade, and thought I would grab a screenshot of the upgrade Wizard in action, with the "Wizard runs SQL" default selected.