I used a very similar method to upgrade Django from a very low version to a very high version where I would periodically:
1) Upgrade the dependencies.
2) Find something that was broken and fix it so it worked on both versions - usually with an ugly if statement.
3) Merge to master and deploy.
4) Repeat 2 days later when I had another spare half hour.
Because it was a pressure cooker environment, the testing was thinner on the ground than I would have liked but mostly because this was an enormous change this whole process took about a year. I actually left the company before I finished off the upgrade and I thought this work had been abandoned.
However, my coworker picked it up after I left and finished off the upgrade in the same way.
Before I joined there were several aborted attempts to do big bang upgrade on the same thing - stale branches that just died by optimistic people who repeatedly thought they could do it all in one go.
>But if you have a good test suite, then there should be no problem shipping the big change in one go!
No, there is. If the change is large enough this is still a horribly bad idea - especially if there are structural changes to data involved. You might be able to make bigger chunks than you would otherwise, but you should still drip-feed large refactorings into production because something can always go wrong. The fewer changes you make at once, the lower chance something will go wrong and the easier it is to isolate and fix the problem if it does.
If you are starting out with a good test suite (something I find almost never exists on a project I'm joining), you should be upgrading everything via small increments and very frequently - negating the need for using this strategy on most upgrades.