该应用程序是一个具有客户和定单跟踪功能的在线定单实用程序。该示例使 COM、ISAPI 和 SQL Server 进行互操作以实现一个 N 层应用程序。
以下是 64 位迁移过程的一些相关特征：
体系结构为一个三层的应用程序：表示层、逻辑层和数据层。
表示层完全包含在一个 ISAPI 模块中
针对它的业务逻辑与 COM 组件交互
将 SQL Server 用作它的数据存储
该应用程序使用 32 位工具集设计和生成，因此在需要时必须迁移代码以支持 64 位。在开发过程中没有针对将来向 64 位的迁移考虑一些特殊事项；在开发该应用程序时，64 位技术还没有发展起来。它由一个非专业的工程师小组开发，旨在使用 Microsoft 技术最好地呈现一个实际的代码基。
 |
| Nile程序架构图 |
该关系图阐释 Nile 应用程序的哪些部分进行了转换。由于将表示层迁移到 64 位没什么直接的好处，因此它仍保持为 32 位。中间层将从 64 位获益，因此它已经进行了迁移，从而使应用程序更具伸缩性、更加健壮。数据层迁移到 64 位，这是因为随着数据库的增长和客户端请求的增加，64 位 SQL Server 将能够按需增长。
数据库迁移非常容易，只需分离数据库，然后将数据库文件移动到 64 位服务器并重新附加该数据库即可。这通过使用标准的企业管理器完成，该过程只需几分钟。多数工作是在实现业务逻辑的中间层完成的。
以下是迁移 NILE 应用程序过程中的几个要点：
需要对涉及到应用程序基础结构的实用程序类进行一些更改。
所有核心逻辑保持不变。这一点非常重要：应用程序向 64 位迁移时不需要开发人员重新设计
应用程序体系结构或修改核心业务规则。
无需对 COM+ 组件予以过多关注，但也需要对它们进行一些修改：
轻微的指针调整：改进并修改指针语句以便符合 64 位体系结构。
一些 64 位调整：针对使用指针引用的语句和获取内存的语句。
迁移到 64 位需要：
涉及到大约 7000 行代码中的 70 行（仅占 1%）。
多数更改包括修改诸如从 LONG 到 LONG_PTR 的 32 位数据类型
转换该应用程序的小组只有三个人，仅仅工作了四天。他们都没有 64 位经验或深入的 C++ 技能。他们将大量时间用在学习如何调试 ISAPI 应用程序 DLL 方面。之前没有人看过该代码，也没有针对 ODBC 进行过编程。这里显示的修改说明了迁移过程并不复杂，实际上所有开发人员都可以很好地完成它。 |
