I’ve never seen engineering teams good enough to withstand conflicting requirements between old and new features. I don’t know what the solutions are, but I’m suspecting the thinking on solving this these days is planning a year or two ahead, publishing the deprecation schedule of old features.
For a balance of practicality and loyalty, I still like the old-fashioned way of doing things. You release version 1, 2, 3, ... of your product. Old versions are supported for a relevant period of time and get essential updates for security and the like, but each major version is its own offering with its own set of functionality, which potentially includes new features, breaking changes, or even removing something.
Users can then move to a new version if and when they want to. Ideally you have a system that migrates their data automatically, including converting to the new way of doing things as needed and warning if there is anything lossy in that process. However, if the user is happy with their old version, they can keep using it without unwanted changes.
Meanwhile, you minimise development costs for ongoing support of older versions. In general, there is no obligation or expectation to backport new functionality. You just release security and compatibility updates as appropriate. You probably also update your migration system regularly, to track whatever you're doing in your newer versions and keep the upgrade path open.
I don't see any inherent reason that the same approach can't be employed even if you're doing the whole cloud-hosted SaaS thing. You just keep the lights on for your existing customers, but direct new prospects to your latest and greatest. IIRC, Basecamp is one business that does something a lot like this.
Perhaps, but then a lot of other software doesn't either. For software that does, obviously a strategy of maintaining multiple versions with potentially conflicting data models isn't going to work.
For a balance of practicality and loyalty, I still like the old-fashioned way of doing things. You release version 1, 2, 3, ... of your product. Old versions are supported for a relevant period of time and get essential updates for security and the like, but each major version is its own offering with its own set of functionality, which potentially includes new features, breaking changes, or even removing something.
Users can then move to a new version if and when they want to. Ideally you have a system that migrates their data automatically, including converting to the new way of doing things as needed and warning if there is anything lossy in that process. However, if the user is happy with their old version, they can keep using it without unwanted changes.
Meanwhile, you minimise development costs for ongoing support of older versions. In general, there is no obligation or expectation to backport new functionality. You just release security and compatibility updates as appropriate. You probably also update your migration system regularly, to track whatever you're doing in your newer versions and keep the upgrade path open.
I don't see any inherent reason that the same approach can't be employed even if you're doing the whole cloud-hosted SaaS thing. You just keep the lights on for your existing customers, but direct new prospects to your latest and greatest. IIRC, Basecamp is one business that does something a lot like this.