我们在4GL（Progress）中有一个包含1000万行代码的应用程序，还有一个包含300个表的OpenEdge数据库。我的老板说我们应该将它迁移到新的编程语言和新的数据库管理系统。 我的问题是：
感谢您的帮助。 Ablo
答案 0 :(得分：4)
除非你的老板能够获得无限的预算，无休止的用户耐心以及对挫折和痛苦的渴望，否则你不应该浪费任何时间考虑重写。
http://www.joelonsoftware.com/articles/fog0000000069.html
是的，进步有一个未来。他们可能永远不会像微软或甲骨文那样性感，也不会像本周酷炫的孩子那样。但他们已经存在了30年，当你和你的老板退休时，他们仍然会在这里。
有些人会对Progress嗤之以鼻，因为它不是X或者它没有Y.也许他们可以在下周末重写你的1000万行代码，并证明他们是多么正确。但是，在用户验收测试通过并且实施完成之前，我不会支付这些费用。
答案 1 :(得分：1)
几年后（原帖是2014年，答案是2014年至2015年）：
得票最多的帖子基本上是双重论证：
一个。 Progress（Openedge）已经存在了很长时间，并且不会很快到来
湾除非你的老板能够获得无限的预算，无休止的用户耐心以及对挫折和痛苦的渴望，否则你不应该浪费任何时间考虑重写：http://www.joelonsoftware.com/articles/fog0000000069.html
关于：
是的，Progress OpenEdge Stack仍然存在。但根据我的经验，找到经验丰富和熟练的Openedge的难度变得更加困难。
但这也是一个重要的因素，我认为这已经发展得更加重要，因为这个讨论开始了：
用于应用程序开发的可用开源堆栈在开箱即用功能和质量方面都得到了更好的因素，并且在RAD的方向上有了决定性的推动。
我正在考虑Spring Boot的例子，但不仅如此，请参阅https://stackshare.io/spring-boot/alternatives。在Java领域，Spring Boot肯定是独一无二的。此外，为了开发丰富的Webui，已经出现了许多非常有效的选项，这些选项当然正在解决RAD的要求，只有一些＆＃34;任意＆＃34; Java的示例https://vaadin.com，Javascript的https://www.polymer-project.org示例，它们与https://vaadin.com/flow有趣地融合在一起。
许多可用的堆栈仍在不断发展，但所有这些都使开发人员的生活变得更加轻松。同样在体系结构方面，您会发现许多堆栈的融合，包括基本构建块和原则：接口与实现的分离，用于远程通信的REST API，对象关系映射技术，NoSql / Json方法等等。
所以是的，开源堆栈在开发方面变得非常高效。还有必要提到的是，这些堆栈的范围并不会随着开发而停止：部署，操作方面以及自然而且测试也很强大，这最终也使开发人员的生活更轻松。
一般来说，可以说选择混合和匹配的开源堆栈有一个非常强大的价值主张，也是在RAD要求的背景下，专有的堆栈，从长远来看难以匹配 - 至少在我看来，我的观点是。
关于b：
有趣的是，我刚刚与一位客户合作，他正在寻求这样做：重写他们的应用程序。具有讽刺意味的是：他们正在从Progress进展到Progress OpenEdge，还有一些额外的Open Edge兼容工具。原因之二是：他们的代码变得非常难以维护并且会进行重构以满足来自Web前端的需求。同样有趣的是，他们找不到足够的合格开发人员。
基本上：代码是健全的，可以重构的，可以重构的，也可以随着新的要求发展。不幸的是，有很多例子 - 至少从我的经验来看 - 相反。
此外，软件终结可以强迫公司，重写＆＃34;至少他们的软件层。而且这并不一定是坏事和不可能。我参与了一个项目，该项目在不到两年的时间内将300多个Oracle Forms表单迁移到基于Java的UI。这种从2层到3层架构的迁移实际上使公司发展其架构以满足Web Ui的需求。所以实际上最终这个＆＃34;重写＆＃34;从业务角度来看，也是一种强大的价值回报。
所以缩短（非常;-)）长话短说：
这种或那种方式，概括很容易出错。
答案 2 :(得分：0)
您无需从头开始编程。有在线帮助，是的，如果您遇到困难，可以联系Progress Technical Support。通常，以前版本的ABL代码应该只进行很少的更改。以下是迁移应用程序时需要执行的一些操作：
备份数据库
备份源代码和.r文件
截断DB bi文件
转换您的数据库
重新编译ABL代码并测试
http://knowledgebase.progress.com文章将为您提供帮助。如果您从某些旧版本（如9）迁移，则可以找到一组很好的新功能。您可以尝试使用它们，但只有在完成转换后才能尝试。
如果要从32位迁移到64位，并且如果使用的是32位库，则需要将它们替换为64位
答案 3 :(得分：0)
我回来的第一个问题是'为什么'？如果应用程序没有衡量这一点，那么需要从这个角度来看问题。
如果认为Progress在某种程度上是一个“较小的”应用程序开发和操作环境，并且只希望 转移到不同的开发和操作环境 - 那么你最终会得到一个投入时间，精力和资金的大量资源 - 更不用说机会成本 - 以及为什么？要在不同的数据库平台上运行？迁移会导致较低的TCO吗？加快发展周转时间？更快的上市时间？从Progress进入的预期优势是什么，以及恢复迁移成本需要多长时间？如果有的话？
在某个地方，有一家公司有类似的想法，并试图摆脱Progress和ABL。这项工作未能达到他们的目标性能和功能指标，因此他们最终放弃了迁移，随意使用Progress - 在花费2500万美元用于项目之后。
贵公司可以承担这种风险/回报率吗？
答案 4 :(得分：0)
Progress（Openedge）已经存在了很长时间，并且不会很快到来。除非你当前的应用程序不能满足你的需求，否则用任何语言重写1000万行代码只是为了使用当月的当前风味是不值得的。即便如此，通常还是能够满足当前的需求。
如果您需要将当前应用程序迁移到最新版本的Openedge（Progress），通常只需复制数据库并将其转换为新版本的Openedge并编译您的代码新的数据库和摇摆错误。您可能会遇到一些关键字问题，但这通常很小。
如果您需要编程方面的帮助，我建议您联系Progress Software并参加年度贸易展或前往https://community.progress.com/并询问/寻找本地用户组。本地用户组将是寻找本地编程人才的绝佳场所。
希望这会有所帮助.....