AとBという2つのアプリケーションがあります。これらのアプリケーションの現在のバージョンは7.xです（7.1を実行している顧客もいれば、7.2を実行している顧客もいます）。両方のアプリケーションは、次のように同じ共通フレームワーク（これをCと呼びます）を使用します。
+---+ +---+
| A | | B |
+---------+
| C |
+---------+
重要な新規顧客がいるため、AとBの機能を1つの大きなアプリケーションにしたいと考えています。AとBを1つのアプリケーションにマージすることは不可能なので、今はAの機能をBに統合しようとしています。これまでのところ良好ですが、いくつかの問題が発生し始めています。
まず、Bの基本機能のみを使用する顧客は、追加されたAのすべての新機能に関心がない（そして、追加のオーバーヘッドが発生する）。彼らは、新しいWindowsバージョンをサポートしてバージョンBをアップグレードしたいだけで、C（共通フレームワーク）に追加されたすべての優れた機能も望んでいるだけです。
次に、現在アプリケーションAを使用している顧客は、アプリケーションBに直接移動したくありませんが、A + Bの機能を組み合わせることで、長期的には役立ちます。アップグレードを簡単にするために、彼らはAを使い続けたいと思っています。
3番目に、Bで行っているすべての開発は、Bのモジュールのパフォーマンスを向上させるために共通層CEgに影響を与える可能性があるため、Cのモジュールをリファクタリングする必要がありますが、CはAでも使用されているため、もっと多くの仕事をする必要があります。さらに、Aは古い、あまり構造化されていないアプリケーションであり、Cのすべての変更はAをより不安定にする可能性があります。
問題はどのように進めるかです。私は現在、7.xリリースでBを分割することを考えています（必要に応じて、ここでいくつかのマイナーな開発とリリース7.3、7.4を今後数年で行うことができます）、および8.xリリース（すべての新機能が含まれます）。 。共通層の問題を解決するために、Cを古いC（7.x）と新しいC（8.x）に分割することもできます。これにより、次の結果が得られます。
+-------+ +-------+ +-------+
| A 7.x | | B 7.x | | B 8.x |
+-----------------+ +-------+
| C 7.x | | C 8.x |
+-----------------+ +-------+
アプリケーションAはもう進化せず、7.xバージョンの共通レイヤーCに固執します。
Cを分割するとは、Cでのすべての開発が古いAとB（まだリリース7.xである）では見られないか、AとBのリリース7.xで行う必要がある場合は、両方のリリースでの開発。
BをB 7.xとB 8.xに分割することもできますが、これはCでのリファクタリングの可能性を制限し、実際には最初の2つの問題のみを解決します。
誰かがそのようなメジャーリリースの変更について何か経験がありますか？他のアイデアは？