Legacy modernisation - Parallel systems vs Extending Original application?

Question

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.

1. 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.

2. 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.

1. 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.

2. 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.

3. 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.

4. 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.

Answer 1

I'm assuming you have a small team and a limited budget, so my answer assumes the following is true:

• Maintaining 2 separate applications would be a big strain on the team
• The work to integrate the new product is non-trivial
• The old product is nearing end of life or is obsoleted by the new product which does the same job better

At this point you have to take stock in what you have, and where the integration points happen. In the comments you mentioned that your app provides visibility into the data that is manipulated by your tool. So I would start out by ruling out possibilities.

• If you were to run both products on the same data at the same time do you have consistent results? (if not, that rules out option #2 at the beginning)
• How much impact would forcing users to make a choice every time they process something be. One or two times a day may not be a big impact, but when it has to happen all day long the impact can significantly impact the amount of work the users can get done.
• Understand how each program communicates its results and what the integration opportunities are.

Assuming that both options are still on the table, you'll have to do a series of targeted rewrites. To do this effectively, you'll need version control software if you don't already use it. Here's how it will go down:

• Pick one goal and time-box it. It should be something you think you can achieve in that time.
• Write down the tasks you think will need to be taken to achieve the goal
• If it looks like you are going down a rabbit hole and the changes are more extensive than you first thought: write down the barrier a step above the task you just were working on and roll back your changes!
• If you found a barrier to your first task, that becomes your new task. Repeat until you get your goal done.

Your time-box is important. This is basically the amount of time you can afford to be wrong. If you beat the time, great. But if time is up and you are only a portion of the way through, you either misjudged or there are other steps that need to be taken first. The time box helps you be honest about whether you are in a rabbit hole or not.

As a first goal, you might look at what interface you need from the perspective of your application to the third party tools. Then separate the logic so that your application calls the right methods in the interface and the implementation calls invokes the right calls to your current third party tool. Implementing a second implementation should be easier once you learn from that process.

Answer 2

Unless end-to-end automatic testing is easy i would go for option 1.

@BerinLoritsch has good points, my order of steps would be to:

1. Reduce dependencies: Abstract all communication to interfaces (for everything check if this is possible with App2)
2. test if code still works on App1
3. Optionally: Try to write as many unit tests as possible that test against interfaces but on App1 (so with specific data that works for this test and is properly reset)
4. Build implementation with App2
5. Test new implementation with the same unit tests, since it is build against the interface this should be easy and a quick gain

On the other hand. both Apps cannot follow/implement the same interface. option 2 is your only go. Make sure you properly research your code before you start.

thus step 0 should be: map (make a scheme of) all current communication between your app and App1 check if it is possible to be replaced with App2.