Doing minor releases to products are easy to roll out without disrupting the adoption and the usage of the overall product. Doing early user tests and a timely communication and a hypercare period facilitates the release. Whereas when releasing a major product change where some functionalities are completely new and some existing functionalities are unavailable for a while, there is a strategic decision to make. There are two main paths: keep the old version for a while in parallel, or move completely to the new one.
Keeping the old version running in parallel for a specific period of time has its benefits. Users who depend on the old functionalities can continue their work without interruption. It also provides an option for users who may be resistant to change to adapt at their own pace. In case the new version has some sort of an unforeseen issue, users can easily switch to the old version that they are familiar with. All benefits mentioned, there are few things that makes this option somewhat less attractive. First and foremost, maintaining two versions can be costly and complex. Moreover, having two versions can confuse the users, especially if there is also a logic differences between the two versions. From resource perspective, development and support teams have to split their focus between two versions, potentially slowing down progress.
Moving completely to the new version is is simpler for users to understand and for your team to support. While team focuses entirely on improving the new version, users are encouraged to adapt to the new functionalities. On the other hand, it is very risky to deprive users overnight from the functionalities and the UX they had. Some users might resist or delay adopting the new version, it could lead to a loss of trust or users.
In order to make the right decision and to release a smooth product change, the following should be considered:
Assess Functionality Impact: Understand which functionalities will be affected and how critical they are to your user base.
User Communication: Communicate with your users well in advance about the upcoming changes, the timeline, and what they can expect.
Offer Support: Provide resources to help users transition to the new version, such as documentation, tutorials, and responsive customer support.
Gather Feedback: Get feedback from your users about which functionalities they cannot live without and why.
Consider a Phased Approach: If feasible, roll out the new changes in phases, which allows time for users to adapt and reduces the number of functionalities that are down at any given time.
Beta Testing: Offer a beta version of the new changes to a subset of users. This can help you iron out issues before a full-scale launch.
Contingency Planning: Have a rollback plan in case the new version has major issues that were not identified during testing.
Data Migration and Compatibility: Ensure that data from the old version is compatible with the new version, or provide tools for users to migrate their data.
At the end, the approach depends heavily on the specific situation, including the nature of the product, the user base, the criticality of the functionalities that will be taken down, and the resources available to support one or both versions. It is essential to weigh the pros and cons in the context of the product and users before making a decision.