Alright, let's do this. I got you, fam. I've done several
2 > 5 upgrades, both small sites and some real big ones.
First thing, so far no client has opted to go the rebuild route. Generally it would take longer than the upgrade process (so more money from them), and I would only recommend it to a site that was in such bad shape (templates are a mess, PHP used in all the wrong places, lots of deprecated add-ons, etc) that I wouldn't choose to take on the upgrade project in the first place because of that.
Second, if you visit https://github.com/ExpressionEngine/ExpressionEngine/tree/3.5.17 and click
Clone or Download you will get the production copy of version
3.5.17. You can get the latest version of
5 this way if you choose.
The thing is, is that EE
5 will have the upgrade scripts to go from
2 all the way to
5. And those scripts are the most up-to-date update scripts, that have the least bugs. The rub is, however, that depending on your add-on inventory, you almost certainly have to go step-wise. Many of the more complex add-ons need to migrate data in certain ways between major versions, so you have to stop at EE
3 and upgrade your add-ons, stop at EE
4 and upgrade your add-ons. I've found the most success in going step-wise, especially with the bigger more complicated upgrades.
If you essentially have no add-ons or very few that have very simple upgrade paths themselves, you actually can get away with going from
2 all the way to
Here is the next complexity; during this upgrade, at some point you'll want to switch from PHP
5.6.x to at least PHP
7.0. This complicates things, but it can be done after the fact.
If you are going to go stepwise, I recommend copying the EE
5 update scripts over the EE
4 and EE
3 scripts (only going so far, so just overwrite the EE
3 update scripts up to the latest EE
3, same with EE
4) because those scripts are the most bug checked at this point.
Also, rehearse the upgrade. Make a throwaway staging server and duplicate your application. If you use a service like Digital Ocean that allows you to take snapshots of a VPS you launch, that is super helpful, so if an upgrade attempt fails on the staging server, you can debug what happened, and just reset easily to a pre-attempt snapshot and try again.
Another thing I've done is add logging to all the upgrade scripts methods. It just logs to a file, something like this at the beginning of each method in each script:
file_put_contents ($_SERVER["DOCUMENT_ROOT"] . "/upgrade_log.php", date("c") . " : " . __FILE__ . " : " . __FUNCTION__ . " : " . __LINE__ . "\n\r", FILE_APPEND);
An extra benefit to this is that if you are logged on to the server, you can tail that log while you run the upgrade like so:
tail -f upgrade_log.php
and watch live. This will also help you gauge some of the slower methods that might be more memory intensive and might be an issue between different environments.
So if an upgrade fails without a useful error, I know what the last fired method is, so I can debug why it failed there.
There's a lot more I could say, but you'd need to ask more specific questions, I've rambled enough. If you have trouble when you rehearse the upgrade, ask more questions.