我们公司有一个软件已经开发了10多年，所以里面有些东西确实过时了。它仍然功能齐全，但我看到了Delphi XE的新特性，这让我想换一个。问题是源代码本身超过300mb的.pas文件(包含组件等总共1gb)。
我们使用自定义组件，旧的jvcl的东西和最新的devexpress。
如果我决定从Delphi 7迁移到Delphi XE，事情会有多难?
谢谢。
唯一真正的问题是转换为Unicode。你应该了解Unicode支持是如何在Delphi中实现的-从Marco Cantu白皮书:Delphi和Unicode开始
在不知道实际代码的情况下估计将旧应用程序升级到Unicode所需的工作量是不可能的。如果您以标准方式使用字符串类型，那么转换将很容易。任何与字符串类型有关的低级技巧(如在字符串中存储二进制数据)现在都已弃用，相应的代码应该重写。
一些小工具不需要做任何修改就可以迁移，或者只需要几个unicode修复就可以运行。
然而，如果你的代码库像你解释的那么大，你不应该完全依赖这里任何人将要告诉你的。只需获取XE的副本并加载代码。看看你会遇到什么问题，感受一下需要付出多少努力。
此时，我已经将所有代码移植到XE(甚至是旧项目)。我尽可能地重用相同的库，所以一旦我转换了其中的大部分，将应用程序从Delphi 7"移植"到Unicode Delphi通常只是一个重复的任务，要么处理库中的更新接口，要么修复编译器错误和警告。我遇到的最常见的错误:
Unicode的东西。这将花费90%的时间。如果代码做了很多低级的字符串处理，这很烦人，但是通过添加一些类型转换，大多数问题都可以很容易地解决。
当你使用编译器会出错。您应该对unicode字符串使用
CharInSet()。如果你设置了ShortDateFormat，你会得到一个编译器警告，你应该使用FormatSettings。ShortDateFormat代替。在新代码中，这是个好主意。如果你正在移植，如果你只是想要继续，那就忽略它。
c in ['a'..'z']时，此外，您可能会将第三方库升级到较新的版本，这样您就不必自己移植这些库了。更改界面或工作方式并不罕见，所以我下载了一些试用版，看看有什么变化。
您在回复评论中提到SQL…您的数据库支持unicode吗?如果没有，你可能会有很多工作要做。您可能需要实时转换数据库，或者为您的用户制作转换工具。您可能需要升级数据库，甚至切换到其他数据库。例如，DBISAM不支持unicode，但供应商提供了支持unicode的ElevateDB。这种转变并非微不足道。而其他一些主要用汇编语言编写的库，如Hyperstring，则是另一个痛点。
我已经做了很多这样的转换。
您应该通过使当前的代码库可测试来做好准备。最好使用自动化的单元测试，但至少要有一个好的最终用户测试计划。
那么你应该计划最大的部分:你的应用程序和数据库的Unicode转换。
最后还有一些不太重要但可能非常耗时的方面:
- 如果你正在使用BDE，现在是时候摆脱它了
- Delphi XE比Delphi 7更严格
- 第三方库版本，它会增加相当多的版本，并且通常远不如VCL向后兼容。
当你移植了它，是时候改变了:因为你已经看到了整个代码库，现在你知道你的弱点在哪里，所以你可以开始重构它们，得到一个比以前更好的应用程序。
我的项目大约有一百万行代码，我最近从CB9移植到XE。为了减少工作量，我首先重写了很多，这样我就不再依赖于第三方组件包，然后仔细检查了所有与字符串相关的内容(unicode)，然后才转移到XE。准备工作很多，实际移植相对容易。
执行这个MIGRATION绝对是一个挑战。但是需要好的计划!
我们首先需要找到所有可能的组件，这些组件也需要与代码一起迁移。如果Delphi7项目中使用了第三方组件，而这些组件是不可用的，那么进一步开发就会变得非常复杂。其次，另一个与Unicode相关的类型转换，非常简单。最后，当然我们还需要其他的支持库，BDE和数据库适配器。
对于富用户界面，可以使用Delphi FireMonkey。
Delphi正变得越来越好，因为它现在支持从桌面到Web到移动应用程序的开发。