I have two applications, called A and B. The current version of these applciations are 7.x (some customers run 7.1, others run 7.2, …). Both applications use a same common framework (let’s call this C), like this:
+---+ +---+
| A | | B |
+---------+
| C |
+---------+
Because of some important new customers, I want to have the functionality of A and B in one big application. Merging A and B into one application is not possible, so I am now trying to integrate the functionality of A into B. So far so good, but I starting to encounter some problems.
First of all, customers that only use the base functionality of B are not interested in all the new functionality of A that is added (and which causes additional overhead for them). They just want to upgrade their version B with support for new Windows versions, … and maybe also want all the nice functionality that is added to C (the common framework) as well.
Second, customers that are currently using application A, don’t want to directly move to application B, although the combined functionality of A+B would help them in the long term. For easy upgrades, they want to stick with A, and even see some improvements in C.
Third, all of the developments I’m doing in B might have an impact on the common layer C. E.g. in order to improve performance of a module in B, I have to refactor a module in C, but since C is also used in A, I need to do much more work. Additionally, A is an older, less-structured application, and every change in C might make A more unstable.
Question is how to proceed? I am currently thinking on splitting B in a 7.x release (I could still do some minor developments here and release 7.3, 7.4 in the coming years if needed), and an 8.x release (which would contain all the new functionality).
To solve the problem of the common layer, I could also split C into an old C (7.x) and a new C (8.x). This gives the following result:
+-------+ +-------+ +-------+
| A 7.x | | B 7.x | | B 8.x |
+-----------------+ +-------+
| C 7.x | | C 8.x |
+-----------------+ +-------+
Application A would not evolve anymore and would stick to the 7.x version of the common layer C.
Splitting C means that all developments in C will either not be seen in the old A and B (which would still be release 7.x), or if they must be done in release 7.x of A and B, would require doing the developments in both releases.
An alternative could be to split B into B 7.x and B 8.x, but this would limit the refactoring possibilities in C, and actually only solves the first two problems.
Does anybody have any experience with such a kind of major release change?
Any other ideas?
1
First of all, customers that only use the base functionality of B are not interested in all the new functionality of A that is added (and which causes additional overhead for them).
This is typically only a user interface problem: bring the functionality of A into your combined application “B 8.x”, but separate it in a way it won’t be seen by the customers of B at the UI level. Build a switch into the application so you can activate the A-functionality only for “A customers”. Probably you need to have another switch to hide the B functionality for A customers (this gives you also a chance to sell them the B functionality as a separate module)
Second, customers that are currently using application A, don’t want to directly move to application B, although the combined functionality of A+B would help them in the long term.
I guess this will be no problem if you care for two things:
- find a way to design your user interface for the “A functionality” in “B 8.x” in a way it is not too different compared to A 7.x
- offer those A customers the transition to B 8.x for the same price as from A 7.x to A 7.(x+1). Or, declare “B 8.x” with the disabled B-functions as “A 7.(x+1)” to the A customers (how to name a follow-up may be a contract issue, you should check this).
Finally, if you can migrate your A customers to B 8.x this way, you will automatically solve your third problem.
One thing to add: I am maintaining an application which was in a very similar situation about 15 years ago (“A 7.x” was an MS DOS program, “B 7.x” was a Windows program with a lot of new features, and “B 8.x” contained all functions of both predecessors, where the old “A 7.x” functions were integrated into B and selled as a separate module). You won’t be surprised when I tell you that we have no MS DOS customers any more since more than 10 years, so the transition was no problem at all.