我的组织手上有很多传统的ASP软件。
由于我们认为微软显然缺乏对其旧产品的支持，我们需要弄清楚要迁移到下一个产品。
如果我们从Classic ASP迁移到ASP.NET，感觉就像是'完全重写'“迁移”。由于情况可能就是这样，我们正在考虑转向免费（如在啤酒和言论中）平台。我特别认为我们的投资（在编程方面，我的意思是）会更好地用于让我们发展的平台，而不是强迫我们每4/5年转储一行代码。这是我们一直用来倡导向“自由”平台迈进的主要论点。
目前我们正在考虑将Java与JRuby或Groovy等动态语言混合使用。
我的问题是：什么是良好的迁移选择？我们的恐惧没有根据吗？我们（可以想象）是否需要在4或5年后重写大部分代码库？你有什么理由转向.NET或免费平台？
答案 0 :(得分：5)
我们最近将一个实质性的ASP项目迁移到了ASP.NET，它绝对有可能进行一次不会完全重写的迁移，保留了原始代码的大部分（尽管我们从一些相当好的架构代码中获益）从一开始就很好地分离了业务逻辑和表示层。
我们查看了两种可能的迁移路径：
作为一个“适当的”ASP.NET应用程序进行重新编写，充分利用内置控件并将所有业务和数据访问层转换为类等 - 即我们接近新的方式ASP.NET项目。
更基本的语法迁移，将ASP页面更改为ASP.NET，而不对结构或逻辑进行太多的前期更改。然后在我们继续开发网站的基础上，通过更好地使用ASP.NET控件，单独的类等来获取新功能和修改后的功能。
由于进度压力，我们采用了第二条路线，允许我们尽早转换，然后对未来发展的更多基本变化采取长期观点。
在此基础上，对于初始迁移，我们能够重复使用大部分现有代码，尽管随着我们的发展逐渐被替换。有一个“普通”页面，比如50-200行HTML和50-500行VBScript代码（作为单独的函数，没有混合到HTML意大利面条样式），我们发现每页需要大约一个小时才能迁移它们，包括将所有ADO数据访问更改为新的ADO.NET数据访问层。一些简单的页面只花了几分钟 - 一些更复杂的页面花了一整天 - 但是大约一个小时的页面就是数百页的总体数字，而改变数据访问的时间代表了工作的重要部分
如果我们今天重做迁移，我们将使用ASP.NET MVC而不是Web表单，因为它更好地映射到原始页面的编写方式 - 尽管我无法评论是否迁移MVC会花费更多或更少的时间。
这不一定与您是否想要迁移到免费平台或更改语言有关 - 您可能有其他理由想要这样做。 （我们的客户端是基于Windows的，所以转向ASP.NET，开发时间放在一边，不需要额外的成本。）但是，我可以说，有可能将一个实质性的ASP站点迁移到ASP.NET而不需要完全重写 - 而且同样可能从早期版本的ASP.NET迁移到最新版本，只需要很少的工作。显然，我们选择的路线，保留代码的一些ASP感觉，而不是选择完全重新开发，可能并不适合所有人 - 但它确实为您提供了一个低影响力的入口点，然后允许您构建在充分利用现有代码库和技能的同时进行基础工作。
答案 1 :(得分：2)
你知道mono存在吗？
我认为你会发现语言的寿命并不像你想象的那么重要，因为应用程序主要版本的生命周期很可能比大多数语言的生命周期都要少。并且公平对待.NET 2.0 - ＆gt; 3.0是一个相当小的转变，而不是“倾销每一行代码”练习。如果你甚至想要升级，这还不是真的需要。
我认为可以针对您可能考虑的任何特定平台提出强有力的案例，我会考虑其他因素，例如您的程序员的舒适/技能/熟悉程度，社区支持，扩展和适用性。
答案 2 :(得分：2)
选择在于贵公司支持您选择的任何内容。
你打算自己支持这些代码吗？如果是这样，你现在的技能基础是什么？
如果你现在正在享受ASP，那么ASP.NET（代码重写或没有）似乎是第一个尝试的想法，即使你没有意识到，通过使用ASP到目前为止，你可能已经获得了很多在ASP.NET开发，部署和支持方面，维护IIS以及可以重用或至少可以轻松适应的众多基于Microsoft的服务和服务器的知识。
JAVA，RUBY，无论您选择什么，任何技术的美感/实用性/功效/可用性/耐用性都取决于其维护背后的人。
您应该提出的问题是：
..等等..
不要在这里和那里分散成本，或者自由与非自由分散注意力。
当技术对于项目背后的人来说是未知的/新的时候，支持的工作时间可能比大多数打包的软件解决方案昂贵得多，这将为您提供支持。
对于需要为IDE / Server /等支付更多费用的开发环境也是如此，但在底线上，您可以获得较少的学习曲线并获得专业水平的支持。
此外：就像@annakata所说的那样，你有很多机会/项目来实现“像啤酒一样免费”的ASP.NET功能..单声道还是不单声道..
示例：如果您喜欢这种事情，可以使用Apache设置ASP.NET服务..
根据您所知道的以及您想要了解的内容选择您想要采用的技术，而不是您认为最新和最好的嗡嗡声，特别是如果您开始考虑重建代码集的全部原因到期微软对ASP的支持不足。
答案 3 :(得分：0)
鉴于行业不断变化，工具，平台和语言不断发展以最大限度地提高效率，我认为您无法摆脱每4到5年迁移的痛苦。无法保证Groovy / Ruby / C＃不会改变以采用下一个重要的东西。
就个人而言，我不会因为自己100％的未来证明而失眠。如果这是目标，那么你也可以使用汇编，即便如此，也不能保证也会保持不变。
请考虑以下事项 1）你们的人知道什么？如果他们是vb家伙，那么转向VB.NET是有意义的 2）您对工具有什么预算？ 3）您想要移动的平台是否拥有您需要的东西？我记得有些时候惊奇地发现Powerbuilder对正则表达式的支持（或缺乏支持） 4）平台周围是否有社区？