We are in the process of modernizing an existing legacy application and as part of that we are replacing a proprietary off-the-shelf product that is deeply integrated with the application - with a new off-the-shelf product.
There are two approaches we are looking for co-existence.
Update the Original application (say App1) to work with both off-the-shelf vendor products (calling them VP1 and VP2). This would mean modifying the existing codebase and updating all integration points so that they work for both vendor products. We are planning on achieving this via an application level switch - so depending on a condition the process flow will use implementation for VP1 or VP2 to process requests. This would mean a single application which has both implementations (abstracted via interfaces) can be used to process requests.
Second option is to have two systems running in parallel during the co-existence period. The way this is being proposed is to create a copy of existing application (App1), remove all implementations for the existing vendor product VP1 and re-implement them with the new vendor product VP2. This new copy of the application will then be hosted as a separate instance (lets call it NewApp1) - and the users will have to switch between the Original (App1 and NewApp1) to perform business functions during co-existence. This is with a view to leave the existing application as-is and not breaking the current functionality. It is also to minimize effort involved in re-testing the entire application (App1) if it is modified.
Which of the two approaches is more suitable in case of an application that essentially is replacing the underlying vendor product?
Edit (30/01)
Adding a little more context and rationale in support of Option #1 (at-least for the use-case that i am dealing with). This is over and beyond what has already been added in the comments below.
It is important to note that the application in question is a monolith - which has been in production for many years. It is fair to assume that multiple updates were made to the application as bug fixes, minor updates which are not documented anywhere but in the codebase.
A downside of creating a copy and removing implementation related to the existing vendor product - and replacing it with new vendor product - would have been that we may have lost those tactic business rules.
As has been pointed out in the responses below, going ahead with Option #2 would have resulted in a cost associated with business change activities due to introduction of a manual process to select which application to use. This in-turn would have resulted in re-training of multiple team.
From an infrastructure point of view - there was a possibility of framework/version incompatibility - when deploying the copy (from Option#2) to our latest standard infrastructure stack. If going ahead with Option #1 it would have been a matter of re-deploying to the existing (albeit non-standard) stack as opposed to re-platforming the entire application to the standard stack (in case of option #2). An alternative would have been to spin up the non-standard stack for option #2 but that would have meant maintenance overhead.