我正在一家拥有以VB6编写的已建立应用程序的公司。该应用程序稳定并且继续为公司提供良好的收入。但是，它开始显示它的时代，并且制造噪音以移植到.Net等更现代的平台。
由于这几乎从来都不是一成不变的决定，因此，在将长期存在的应用程序移植到现代平台的最佳时机，我将不胜感激。
我已经经历过的一些利弊：
[赞成移植
反对移植
一些与StackOverflow相关的问题：
要考虑的事情之一是，随着时间的推移，移植应用程序会变得越来越昂贵。我看到用“古老”语言编写的应用程序非常发达。但是，就像很多次一样，所有领域知识都在代码和开发人员的头脑中，而不是最新的文档中。
因此，在这种情况下，移植不仅意味着要用新的闪亮语言重写，而且还要对规范进行反向工程，并吸引开发人员的希望。随着时间的流逝，这变得越来越难。
另一件事是，“移植”从未像迁移向导希望我们相信的那么容易。许多向导产生了一个半生半熟的解决方案，该解决方案仍根据“旧版”环境的通用构造和功能构造而成，并且几乎不会使用新功能和可能性。这看起来似乎还不错，但是如果您将其保持在该水平，则实际上会使知道“新”语言的开发人员很难理解代码，并且更难移植到下一个平台或语言。这就是我所说的首都遗产。将useless东西拖了几十年。
从开发人员的角度来看，开始移植的最佳时机是昨天。
从经理的角度来看，开始移植的最佳时机是明天。
从竞争对手的角度来看，开始移植的最佳时机永远不会。
还有许多其他需要评估的因素：机会成本（我们可以做些什么），可扩展性和增长能力（应用程序需要做/要做的其他事情），其他活动部件的可持续性（数据库升级，操作系统升级）等。列表不停地打开。
特定于VB6，我将评估在产品开发与升级到当前.Net框架方面的哪些限制。问问自己-这真的是IF场景，还是WHEN场景？
从一般的角度来看，移植应用程序的最糟糕时间是必须移植时。您的情况听起来像是开始进行代码迁移的理想时机-在这成为必要之前。考虑到您的旧产品对公司的盈利能力，任何被迫迁移的情况都会在截止日期，范围等方面带来压力。
考虑到所有问题，您的情况听起来像是在需要时移植到.Net Framework的理想时间。
回音，尤其是Erno，
[没有称职的开发人员会接受纯粹的移植工作，这不是促进职业发展的举措。但是，作为移植工作的一部分，现有的开发人员将乐于学习最新的框架。
VB6于1998年发布。March 31, 2008 Microsoft EOL'ed all VB6 support.到目前为止，您的公司使用此代码已进入危险区域，这很可笑。
要添加一些观点，
在某个时候，由于操作系统将不再支持api，因此该公司将被迫升级该应用程序。
您应该离开这家公司。留下来是职业的死亡。
因为Cody认为“我是个人开发者”，所以进行了更新：
@@ Cody-重新考虑您的假设。我经营自己的公司。毫无疑问，每次我们落后于平台的最后一个稳定版本时，追赶工作都非常痛苦且昂贵。最新的痛点是我们在dojo 0.4.3和Tapestry 4上。T4和dojo 0.4.3具有这种相互依赖的关系，我们正在分开（慢慢地）。迁移到Tapestry5和/或jquery甚至只是迁移到最新版本的dojo都是非常缓慢且非常痛苦的。移植已经花费了一年多的时间，因为它必须经过漫长的过程才能保持其他开发的进展。
选择是：
到目前为止，我们一直在组合＃2和＃3。
使用旧版本的dojo或挂毯意味着我们失去了社区支持我们并帮助我们解决问题的能力。框架的优势在于，其他人正在从事解决[[your问题的工作。没有人可以解决任何VB6问题了。 Microsoft甚至不花钱来解决VB6问题。
OP的公司完全依靠自己。注意：Google成立于VB6发行之年。我会怀疑VB6的知识已经从网络上消失了，而且每年Google搜索OP公司制造的任何编程问题都会返回越来越少的结果。这是业务生存风险。
关于永远支持VB6的MS的愉快讨论不是一个好主意。微软的一位高级副总裁说：“如果团队不必解决仅影响VB6的这些问题，我们可以及时提供Windows的下一个版本来过圣诞节。我们稍后将发布Service Pack。”在某些时候这可能并且将会发生。竞争对手可以更快地使用最新工具来推出竞争产品（因为使用最新框架时可用的库很大。）OP的公司失去了灵活的能力，因为最新的工具和库不再支持VB6。 （一个13岁的框架！）
这是另一个业务生存风险。
需要向任何人解释这一事实，对任何在OP公司面试的经验丰富的开发人员都是一个巨大的警告标志。这极大地降低了人才库的质量和数量。
无法吸引优质人才是另一项业务风险。
原始OP应该保释。
不仅限于Microsoft，Windows还将支持该应用程序。打印机之类的东西呢？或显示？爱普生没有义务发布支持VB6应用程序的打印机驱动程序。OP应该在裁员之前继续前进。