upgrading multiple versions of EE to php 5.5

Question

For security reasons we were recommended to upgrade to the latest version of php (from version 5.3 to version 5.5.X) to fix all the possible bugs out there for that version, however I'm a little bit worried because we have more than 100+ sites in EE (Versions 2.1,2.2,2.3) and if we upgrade our PHP the websites could stop working.

• Am I worrying too much for this? or there's something that I should consider before make the big upgrade

Answer 1

Totally agree with Steven's comment, I'll give my own answer though as we recently went through similar.

We were migrating to a new server and took the opportunity to build php 5.5 on the server to skip a version and save us the hassle of any major version upgrades again anytime soon. Here was our strategy.

1. Upgrade all sites to latest EE build
2. Upgrade all addons to latest build. As part of this we didn't only look at versions of addons on Devot-ee etc, we also checked the various addons respective Github repos etc, as often there were more recent versions that had not necessarily been pushed to Devotee, on a case by case basis if we thought the fixes on Github were worth taking we did testing with that version and went live with it if we had no problems.
3. We already maintain a spreadsheet showing all addons running across all sites and what version they were at. We then identified a test group of sites that covered all the addons across all our sites
4. Using the above list we came up with a test plan that would allow us to test all the major functionality in each site provided by both EE and addons
5. Before our server went into production, we migrated all our sites that were part of our test group and did extensive testing on these sites, knowing that in most if not all cases, the extensive testing we do here should cover most of the other sites as there should be no major differences to the php code between the sites.
6. Once we resolved all our issues with this test group, we ensured we also had a good copy of php5.3 on the new server, this meant if we did run into any issues due to php incompatibilities, we didn't have to roll back every site, we just switched the site experiencing the problem back to php5.3.

The key in the above strategy was to identify all the areas to look for problems before they occurred. Remembering that a php issue may only show up when a particular function runs. For example, the only significant problem we had in the migration was when last minute we removed imap from php, thinking it wasn't needed. When in actual fact Escore (mail sending addon), required this even though it didn't use imap. The only time this error would fire was when email was sent. It was a quick fix, and error was found quickly because testing email was part of our test routines.

If your doing a same server upgrade of php and don't have access to a cloned development environment, I would suggest looking at running two versions of php on the server, then you can move one site at a time which will cause you less grey hairs! How you would do this would depend on your setup, but that's a bit off topic here.

Personally it would never attempt a move like this with EE on 2.1/2.2 etc, they are getting a bit old now. If you do run into problems and seek help, your going to be asked to upgrade them anyway so best get it out the way while your in a stable environment first. Otherwise you could end up in a situation where every site has a different issue to troubleshoot and you will quickly get overrun with issues.

For what it's worth I'm not sure I would consider php 5.5 more secure than 5.4, in fact I think it would be fair to call 5.4 more mature as it's been in production for much longer. I'm not saying don't upgrade to 5.5, but don't automatically assume it's the most bug free version as that may not be the case.

Answer 2

I wouldn't go updating a production server without running any tests first. I'd mirror your production server first and then test the sites individually.

That's the only way you'll guarantee to be headache free.