Making a breaking change is just about the most destructive thing you can do in a software system. Doing something that means everything that went before is outdated means you are going to severely limit your options for the future.
A breaking change is one where the system has changed in such a way to mean you cannot go back to the old version.
If you can’t go back to the old version, then you need to be certain that your new version will work. That may sound pretty simple, but it’s always harder in practice.
You should design your system to reduce the number of breaking changes, and to allow for the simplest methods of coping with a breaking change.
When you have the choice of a little extra work to make a smooth transition, give enough weight to the prospect of your change failing to estimate correctly. Don’t just assume that everything will work and you can always roll forwards.
If you can isolate your breaking change to a single layer then you can split your deployment to several pools. You need a way to send users to the new or old code in a reliable way, otherwise this will not work.
If you design ahead of time to take account for the breaking changes, then when you finally need to make one it won’t be as painful as it may have been.