First, keep the code version somewhere like version.txt and increment.

Second, use gates like:

if (version >= x.x.x) { include new db fields }

Third, add version in your data. This way, for backward incompatible changes, you can have a message like:

$codeVersion = file.read(version.txt)
if (order.version > $codeVersion) {
Print "This order was created on newer software. Please use order.version (or beta website) to process or view this order."
// maybe redirect
}

Fourth, You must release backward incompatible changes in two phases (two version increments): phase i) push the above gate to all users, so it can check for a new version before reaching code that breaks. ii) once the gate exists for all users, release the next version and run the database migration.

Fifth: Add a comment "remove this block once version x.x.x+ moves from beta to www (or all users are on version x.x.x+)."

Sixth: keep a "change_management.txt" of all the steps you must follow when doing a release. It should contain reasons you broke things and a step so the same break never happens again. This list should be surprisingly short once you have a documented release process. For example

"Did you remember to update dependencies? Did you audit/patch or mitigate any new security vulnerabilities? Did you remember gates? Did you remember to turn on maintenance mode if needed, and run db migrations when code was released? Do you know how long db migration will take (for long running db operations, is down time acceptable?)