性能由于您有100，000行代码，在速度快10倍的虚拟机上执行代码（正如adobe所言）肯定会提高性能。但当前应用的性能如何？如果它足够好，那么您真的不应该考虑这个专业。
可维护性和可重用性如果当前的代码库难以维护并且不可重用，那么它需要重构，而不是用新语言重写。AS 3鼓励有助于可维护性和可重用性的编码实践，但这并不意味着您和您的团队将遵循它们，使用AS 3也有可能最终得到难以维护的代码库。还可以以可维护和可重用的方式重构AS 2代码。
新技术我相信这是这里唯一真实的的专业人士。Flex/AS 3是一项新技术。它是一项漂亮而干净的技术。很多人都强烈支持它。Adobe正在推动每个人从AS 2转向AS 3。雇佣新的AS 2开发人员将变得越来越难。支持AS 2的开发工具将越来越少。我猜你迟早要换掉的。

所以，我认为，尽管这里列出了所有的优点和缺点，但你需要让你的客户明白，如果你打算定期更新应用程序，这迟早是要做的。我认为你不应该急于这样做。

Wikipedia提供了一个按Flash Player版本列出的新功能列表：
http://en.wikipedia.org/wiki/Adobe_Flash_Player
从版本9开始的所有内容都只对AS 3可用。下面是一些亮点，包括我自己的一些补充：

• 支持Flex 2+（版本4将于明年初推出）
• 支援Adobe AIR
• 二进制套接字
• H264 / AAC支持
• 3-D转换
• 新的文本布局引擎
• 硬件加速

编写了在FP 8下运行的Flex应用程序（Flex 1.5）和FP 9 +（Flex 2+）我可以告诉您，它的速度明显更快。对于人们每天花费大量时间使用的业务应用程序来说，我认为这是一个显著的改进，可以减少最终用户的烦恼。对于低-级别的操作，如字符串连接和数组排序，但这些指标并不等同于您在真实的世界的应用程序中看到的性能提升。在现实中，它们将更小，但可测量。
最后，你能做的最好的事情就是估计一下保持应用程序原样的成本与重写和添加后续特性的成本。如果他们不打算对应用程序进行太多的修改，那么重写可能就不值得了。但是，如果应用程序添加了许多功能，并且您认为使用Flex和AS 3可以显著提高工作效率，那么您应该能够向他们展示这些数字然后让他们根据这些来做决定。

升级的最大和最重要的原因是，就Adobe而言，AS2是一种死语言。AS2在它自己的特殊VM（准确地说是AVM1）内运行，该VM与Flash播放器的其余部分沿着永远停留在Flash 8的世界中。没有任何新功能或优化将永远回到AS2时期。
此外，如果这个应用程序将长期存在，那么了解AS2的开发人员数量将随着时间的推移而减少，这一点很重要。如果应用程序将跳转到AS3，那么越早做越容易（而且可能更便宜）。

其他答案已经很好地涵盖了这些基础，但我只想指出性能方面，编写良好的AS 3的脚本执行在AS 3中的执行速度往往是AS 2的3到100倍。根据所执行的操作，速度有很大的不同。但是请注意，对于大多数应用程序来说，性能问题并不完全或甚至主要是由于脚本执行造成的。通常呈现是最大的瓶颈，在这种情况下，切换到新的AS 3VM可能会产生中等程度的好处，甚至可能根本没有好处。
我同意其他评论者的看法，最大的问题是许多新功能只能在新的虚拟机中工作。请记住，这不仅仅是一个切换语言的问题-Flash播放器目前有两个不同的虚拟机，而AS 2虚拟机现在基本上是一个传统的应用程序。
还有一件事其他人没有提到-AS 2和AS 3内容之间的互操作性非常差。如果你可能要加载外部内容（SWF），或者尝试使用第三方库（图形组件，或者类似的东西），你可能会看到大多数这样的内容已经是AS 3了，而AS 2的东西只会越来越少。

AS 3上级AS 2--以上有很多原因，包括VM性能、更严格的编译器以强制执行更干净的编码实践（严格的类型等）。我没有看到任何人提到在AS 3中可以在运行时更改对象的父对象，而在AS 2中不能这样做，如果遇到这个问题，你就会知道这是多么令人失望。
但是，更重要的是，当你用AS 3编写代码时，它们会按照它们应该的方式工作。没有什么奇怪的AS 2东西，你会发现bug、缺点，以及代码限制导致的奇怪结果！
如果您正在考虑移植/重写，您还应该考虑如果您的开发团队对AS 2有经验而对AS 3没有经验，您可能必须等待的任何学习曲线。
拥有100，000行代码库（这对于任何ActionScript标准来说都是相当巨大的），除非代码被记录、优雅和有组织，否则移植将是一场噩梦。你可能会发现，从头开始重写，从为应用构建一个更高效和有组织的框架/设计模式开始，最终会显著削减代码库的大小......也许它只需要50，000行的代码库吗？
祝你好运！

我个人从来没有胃AS 2和避免语言完全之前3。有很多原因已经张贴的其他人，但这里是一个快速清单小康的顶部我的头：

• 创建可重用代码更容易
• 您可以遵循经过生产测试的最佳做法
• 访问坚实的微架构框架（Robotlegs、Swiz、PureMVC、Mate、Parsley等）
• 提高速度
• 不局限于Flash或Flex，可访问两个组件库
• 充分利用新的播放器功能
• 访问AS 3已经带到现场的库的加载
• 能够使用Flash Catalyst等即将推出的技术
• 强大的IDE，可提高效率和与大型团队合作的能力
• 不与f 'n时间线联系在一起。

对我来说，选择不是Flash/AS 2和Flex/AS 3--你不会失去Flash......根本不会。你只会得到Flash、Flex和纯AS 3。

我建议将一个100，000行的应用程序从AS2移植到AS3和从头开始完全重建没有什么不同，考虑到它所花费的时间。你会发现这100，000行中的许多行甚至可能是不需要的。如果代码中包含任何类型的框架等，我会更加担心，因为你可能必须自己移植这些。在这一点上，你还不如从头开始。你的客户需要考虑他们希望这个项目能生存多久。如果不到几年，我说不用麻烦了。如果这个应用是他们的全部业务，我说是时候使用2.0版本了，当你在AS3中重写特性时，花时间改进应用的功能和可用性。

AS 3并不优于AS 2

我不太明白这整个抨击AS 2的事情......我知道只有很少的人真正理解AS 2的巨大可能性...... AS 2可以与Ruby相比，而AS 3只是Java 10年前的样子......是的，它很慢，但是它比AS 3功能更强大，表达能力更强......我不知道AS 3有什么基本特性而AS 2没有（不要混淆语言和API），除了正确的错误处理......关于一个无关的主题，我最近得到了细节...... AS 3可以访问一个更大的API，但大多数重要的东西都不是你在业务应用程序中真正需要的......
AS 2可以是高效和优雅的，如果您实际上充分使用它的话......如果您希望在AS 3中获得与AS 2相同的灵活性（或者至少是您可以获得的最佳近似值），您将发现您的代码执行加速的大部分都超出了范围......

不使用AS 3

我是认真的...如果您希望以AVM 2为目标，请通过MXML使用Flex，尽可能减少AS 3的数量，或者使用Haxe...如果快速开发对您很重要，请使用Flex，如果性能更重要，请使用Haex（当然，还有其他原因需要这样做，但我猜这些原因更主观）...
直到今天AS 3一直是一个死胡同...语言自从推出以来一点也没有改变...当然，FlashPlayer有新的功能，但是AS 3自从3年前发布以来就一直停留在AS 3上，除了Vector，这是一个相当虚假的事实...您可能需要注意，从AS 1到AS 2花了3年时间，从AS 2到AS 3又花了3年时间...现在是时候部署AS 4了，但Adobe似乎并不致力于这样的事情...相反，他们越来越专注于扩展他们的产品调色板...

您应该怎么做？

我得到的潜文本的印象，你有大约100000行意大利面条代码...所以实际的问题是代码，而不是语言...你需要做一个重写...如果你认为它有意义，您甚至可以在AS 2中重写它，（尽管我仍然建议使用Haex）......实际使用AS 2的唯一要点是可以复制和粘贴一些实现，如果你幸运的话...但是你真的应该从头开始构建一个干净的应用程序，使用你所使用的语言所提供的最好的东西，作为OOP，AOP和FP的子集（Haxe/AVM 1将允许所有这些东西）或者声明性方法，就像MXML所允许的那样...
除了明显的问题，也就是成本，重写没有缺点...优点是你最终得到了一个更好的代码库，更可维护，更灵活，甚至可能性能更好，或者至少它使剖析和以后的优化更容易...一种语言的表达力是一个因素，当谈到写好代码时，仅仅是因为开发人员很懒，但除此之外，除了性能和工作效率之外，它对任何事情都没有影响...

当涉及到客户时...

......我建议你告诉他们一个简单的事实：他们可以拥有以最低价格提供一组固定功能的软件（这可能就是他们现在所拥有的，在你的情况下），或者他们可以有灵活/可扩展/设计良好的软件...即使他们选择后者，他们也将不得不接受，每隔一段时间你就需要采取激烈的步骤，比如重写......代码的不断降级是一个不可否认的现象......当你设计一个软件时，你开始决定它可以朝哪个方向发展，而它不能，你会到达一个点，在那里，肮脏的黑客添加到实现功能的模糊网络，这是软件没有布局，将使任何进一步的扩展不经济...不要犹豫地指出你的客户，当一个软件你要扩展（不管是不是你的），这是一个非常好的点重写，而不是让他们支付所有的低效工作需要添加额外的功能，他们需要...软件扩展的成本呈指数增长...重写后，此成本将返回到“接近0的浅部分......”这取决于您自己的专业知识来确定，此时执行重写更有意义（如果仅仅为了实际执行此评估就需要查看100 K行代码，那么在我看来，这显然是重写的好时机）...了解您认为软件应该发展到什么程度，需要什么，并选择最有效的方法来做到这一点。

我会在升级应用程序代码库之前扩展硬件（特别是如果你认为升级很困难的话）。扩展硬件会更快更便宜。