I've seen them take well over a day, but I'm looking at systems with millions of issues.
You will generally find that the upgrade time is a function of target version (minor effect), power/speed of your server (a bit more important), complexity of the data (significant), and sheer volume of issues (the primary factor). It really is a function of the sheer amount of work a system needs to do.
There are a number of steps an upgrade goes through:
- It dumps a backup by default
- It then makes structural changes to the database if needed, and converts any data that needs to change shape.
- It then goes over all the data that doesn't need to change shape, but may have modified content
- Finally, it runs a full index
These have different dependencies. All are directly affected by the volume of your data and speed of server. Complexity of data only slows down database and data changes. The versions you are going through matter as a multiplier - the larger the jump in versions, the more likely that there are more data structure and content changes needed.
You can do a couple of things to speed it up.
If you are doing your own backups before starting (as you absolutely should - copying at least the home directory (possibly without attachments) and dumping the database), then there is a flag you can set to skip step 1.
If you are doing more than one step, then you can also turn off the indexing - this got my most recent upgrade run which was 6.4 to 8.13 (so stepping through 7.0 and 7.13) from 9 hours down to a shade under 4 - indexing 7.0 and 7.13 was taking 2 hours each, indexing 8 dropped hugely though, as it's got a hugely upgraded index system behind it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.