我正在处理一个有着几十年历史的复杂系统。它曾经是一个客户端/服务器调度应用程序，但它变得更加复杂。最初，每个客户都有自己的实例，在自己的服务器上运行。现在，我们有一些客户仍在这种模式下运行，但我们也有一些客户在软件即服务模式下运行——所有应用程序都在我们的服务器上运行。我们还添加了 Web 界面，我们有数百名客户仅通过 Web 访问他们的系统。
就目前而言，系统的每个安装包括：
- 一个数据库：其中几乎每条记录都有一个以“customerid”开头的主键，因此多个客户可以针对同一个数据库运行。
- 安装目录：SAN 上的一个目录，在其子目录中存在可执行文件、日志文件、配置文件、基于磁盘的队列以及系统中涉及的几乎所有非网站的其他内容
- 后台应用程序：一堆应用程序，位于安装目录的子目录下，但可能运行在一个或多个应用程序服务器上，负责与各种异地系统、移动用户等进行通信。它们可以配置作为 Windows 服务运行，或从命令行运行。
- 客户端应用程序：另一组应用程序，位于同一子目录中，但运行在任意数量的用户机器上，管理者和调度员可以与系统交互，将工作分派给各种移动用户，运行完成工作的报告等.
- Web 应用程序：几个网站/应用程序/服务，允许调度用户执行某些调度功能，并允许移动用户从任何 Web 浏览器完成分配的工作。通常，网站和系统安装之间存在多对一的关系。我们将在多个服务器平台上拥有多个站点，这些站点配置为针对系统的任何特定安装运行，并使用负载平衡器在它们之间分配传入用户。
我们有十几个不同的安装，每个安装从一个到几百个客户。（每个客户从少数到几百个用户。）
较旧的后台应用程序是用非托管 C++ 编写的，而较新的后台应用程序是用 C# 编写的。客户端应用程序是用 VB6 编写的，针对用非托管 C++ 编写的 COM 对象运行。网站和服务是用 C# 编写的 ASP.NET 和 ASP.NET/MVC。
显然，多年来，它变得相当复杂，有很多部分和很多相互关系。它仍然有效，并且运作良好，让我感到惊讶。让我觉得我们做得还不错，20 年前我们第一次设计的时候。但...
在这一点上，我们最大的问题是安装更新和升级所需的工作量。系统的大部分是解耦的，所以我们可以毫不费力地改变一个通信程序，或者修复一个网页等等。但是对数据库模式的任何更改都需要在系统范围内进行更改。这需要大量时间，会影响许多客户，并涉及重大风险。因此，修复的实施会延迟，这使得我们进行升级时的风险更高，从而导致更多的延迟，并且通常会损害我们的响应能力。
因此，我正在寻求有关我们可能进行的架构更改的建议，这将使升级的风险和成本更低。
在我的理想世界中，我们永远不会升级正在运行的安装，我们会并行安装升级，测试它，一旦我们确信它可以正常工作，我们会将客户从旧系统转移到新系统，一次是第一次，然后随着我们越来越有信心，然后批量进行。如果事情不起作用，我们可以将客户回滚到旧系统。但我看到了一些问题：
- 在用户登录之前，我们不知道用户属于哪个客户。
- 将用户从一个系统移动到另一个系统涉及复制数十万条数据库记录，并在此过程中应用架构更改。
- 将自定义从一个系统移动到另一个系统涉及复制谁知道我们基于磁盘的队列中有多少文件，以及其他各种支持文件。
- 我认为回滚是必要的。但这会更加困难。
我们所拥有的正在工作，但效果不佳。我希望得到一些建议。
确切地说，我不是在寻找答案，但更多的是我在寻找关于在哪里寻找的想法。有人对我在哪里可以找到有关如何处理这种规模的结构化系统的信息有任何想法吗？