我们是一家规模很小，非常专业的福利管理公司，拥有非常有用，功能强大的软件集合，其中一些是用COBOL编写的，但大多数是用BASIC编写的。在过去的30多年中，有两名全职顾问稳定地维护和改进了该系统。不用说他们即将退休。（他们中的一个人已经迫切退休了，但是忠于错误，所以尽管丈夫坚持高尔夫应该优先考虑，但他们仍然坚持下去。）

我们开始了向该系统的转换，该系统由该国仅有的三家提供我们所用软件类型的公司之一开发。我们现在认为，尽管该公司理论上有能力完成转换过程，但是他们没有及时完成转换的资源，并且我们已经开始相信他们将无法提供我们需要的那种服务我们的业务。（没有什么能够设定自己的优先级并有权按自己认为合适的方式分配资源的。）

硬件不是问题-我们能够在现代服务器上非常有效地进行仿真。如果COBOL和BASIC是现代语言，我们愿意冒着风险，可以为未来的现有顾问找到替代品。

一家IT支持公司似乎应该有一种业务模型，该公司应专注于这样的旧平台，并提供编程和软件开发人才来支持像我们这样的系统，从而避免了寻找合适的编程人才的风险。说服年轻的程序员，他们可以有一个富有成果的，有回报的职业，这项工作的一部分是使用一种古老的，非性感的语言（例如BASIC）。

简而言之，作为非IT经理，我们如何最好地管理这一过渡？

似乎“应该有一家IT支持公司的业务模型专注于这样的旧平台”，但我个人认为这只是您的一厢情愿，因为它将“解决”您面临的挑战猛扑

停留在旧环境中并不是前进的路。而且，我不会将任何公司的一生押注于试图找到一家目前会愿意做您显然做不到的事情的公司来保持困境。

因此，这不是您所提出的实际问题的答案，而是关于在如何将迁移风险降至最低的前提下如何前进的真诚建议。

阅读“如何在不失去理智的情况下进行彻底的重写而生存”

不要因为长期没有实际结果而进行长期迁移的错误。阅读“如何在不失去理智的情况下进行彻底的重写而生存”

我不敢强调这篇文章中的建议如何帮助我以“旧的”方式完成这类项目后解决/解决类似的问题。

设置自动化测试

如果您尚未安装它（为什么没有？），请当前的程序员为您的应用程序创建自动测试工具。

自动化测试套件应涵盖您应用程序的所有功能区域。它将/将在各个测试用例的“ when_X_then_Y”规则中记录当前的工作规范。这将有助于防止当前代码中的更改破坏现有功能，并支持向新环境的任何迁移。

在处理COBOL和BASIC时，测试套件可能应该处于集成测试的级别：处理一组“固定”的输入文件/数据库，并检查特定程序（COBOL）的输出文件/更改的数据库内容。 /或应用程序。对于您软件的BASIC部分，这可能意味着添加命令行参数，以使它们执行某些功能而无需（G）UI干预，或者获取基于（G）UI的自动测试工具。

隔离计算和其他算法

甚至Cobol也支持可从主程序调用的子程序的概念。将所有导入计算和其他算法隔离在单独的程序或模块中。目标是创建一个程序/模块/执行所有与收集输入和创建输出的一切隔离的繁琐工作的库。

调整测试工具以通过旧应用程序以及单独进行测试。这将确保您在“旧”代码上所做的工作（以促进向新环境的迁移）将尽可能减少错误。

在“当前”环境中启动一组新的应用程序

不要转换您当前的代码。将一种语言转换为另一种语言意味着对新环境施加旧环境的约束。结果常常不尽人意（请阅读：结果将是可怕的，很难维持）。迁移。花时间在新环境中以被认为是最佳实践的方式来设置您的应用程序。

聘请精通所选环境的新程序员来这样做。从第一天开始，就将所有重要的计算和算法隔离在单独的类和/或程序包中，并将它们隐藏在接口之后，将其作为优先事项。使用依赖项注入（最便宜的DIY依赖项注入方法）来告诉您的新应用程序要实例化/使用哪些类来进行计算。

无论如何，这是一个很好的处理方式，在您的情况下，您可以根据情况迁移这些重要部分。它还将在新环境中从调用函数中隐藏调用基本和/或cobol程序的复杂性。

不要再设置应用程序，也可能要设置单个最重要的输入/输出功能，该功能使用来自COBOL / BASIC“库”的计算。

集成您的COBOL / BASIC“库”

弄清楚如何从新环境中调用您的COBOL / BASIC“库”。这可能涉及设置参数文件或数据库表，执行包装您之前设置的COBOL / BASIC库的COBOL / BASIC程序。如果幸运的话，您的BASIC版本可能允许创建可以直接调用的DLL。

在新环境中实现该类，该类将称为COBOL / BASIC“库”，并使用与旧环境的测试工具相同的测试来对其进行测试，但现在以新环境中的单元测试的形式进行。

是的，这意味着“复制”测试，但这是您不想要的安全网。仅仅是因为这些单元测试以后将用作在将计算和算法迁移到新环境时检查计算和算法的实现的测试。

但是再说一遍：除了为上一步中最重要的一个使用的计算添加单元测试外，别无所求。

充实迭代中的新应用程序

通过对旧应用程序中的所有功能重复前两个步骤，充实新应用程序。继续将那些检查计算的单元测试添加到新应用程序的测试工具中。使用集成测试套件来检查迁移的功能是否与您的旧应用程序相同。

迭代迁移核心库

最后，将计算和算法迁移到您的COBOL / BASIC“库”中，在新环境中重新实现它们。再次，使用（单元）测试来反复进行此操作，以保持理智。

听起来此应用程序是您业务的“核心”。如果系统或流程是您的业务，那是拥有自己的自定义解决方案的情况。

您提到了这一点。不幸的是，考虑到自更新技术以来已经花费了很长时间，这将是一项极其困难的任务。

我建议两条路线之一。

1. 如上面相当技术性的回答所述，由一组IT人员组成开发人员/项目经理/ QE /操作人员，并逐步构建您的系统。但是，这将非常昂贵。
2. 与其寻找现成的提供商，不如寻找合格的定制开发顾问。该小组将处理所有资源来构建您的新系统，然后您可以将其带到比选项1少的职员的内部进行继续。此选项具有不同的风险集，但是，对于非技术人员而言，选择良好的提供商可能非常困难。由于成本超支等原因，它们也可能具有很高的风险。为缓解这种情况，请使用您现有的员工为您的出价制定一套非常详细的要求（从用户角度）。然后还要求提供固定价格的出价。

祝您好运，您还有大约20年的历史需要克服。它不会便宜，容易或干净的。

与其寻找一家公司来维护您的遗留软件或寻找一家公司来重写您的遗留软件，不如寻找一家提供持续收益管理系统服务的公司。将决定是否重写软件，设置时间表，使用哪种语言或工具的问题外包。

是的，这种方法的明显成本可能会超过雇用新程序员的明显成本，但是，根据您自己的承认，您是非IT经理，并且很容易预见到这样的情况，即您做出的决定最终会使公司付出的代价比明显的外包成本。