> should never update a user interface without allowing the previous one to be used as the default Careful: Many UI changes are just branding refreshes. (How f

> should never update a user interface without allowing the previous one to be used as the default Careful: Many UI changes are just branding refreshes. (How frequently do Coke cans change?) But, moving around the buttons because someone felt like it is just dumb. > should never change the format of data already stored on the system Careful: Internal databases change schemas. It's impossible to keep a database schema through upgrades when new functionality requires an updated schema. This particular request really depends on what the application is doing. For example, if an upgrade decided to automatically convert .doc files to .docx, that's a problem. But applications that maintain internal state need to be able to fix bugs or make general improvements to that internal state. > must allow a revert to the previous situation Software doesn't know the future; it can't handle schemas that didn't exist when written. More specifically, if an upgrade alters an application's internal state to match what's needed for a new version, there's no easy way to go back to the old internal state.