在上一篇文章《从RISC迁移到X86平台的原因及技术难点》中，主要介绍了，当前环境下，越来越多的用户正在转向x86平台，并且探讨了其原因和在迁移过程中应注意哪些方面。而本篇文章将介绍如何从Unix平稳迁移到Linux系统。
从Unix迁移到Linux，在最初阶段，应该建立一个沙盘环境用于测试。也许您的整个团队都没有Linux方面的经验，有这样一个沙盘环境能帮上大忙（无需担心任何风险）。
有关代码和编译的问题。你正在使用JAVA还是C？是否有第三方应用需要迁移？这些第三方软件能移植到Linux上吗？
假设您正在使用C语言。假设您将会在Linux上编译代码。如果使用GNU（gcc）编译器，因为这是工业标准，而且这是Linux自己的编译器。那么所有在其它平台上编译过的应用程序都需要重新编译。
对于编译，有两种方法供您使用。一个方法是在现有环境上重新编译您的程序，这种情况下，您必须确保在这个环境下有您需要的所有工具，其中包括源代码和生成文件。如果您想使用这个方法，请在您的测试环境中进行，永远不要在生产环境中实施。
另一种方法是把所有数据和代码移植到新环境上，并且测试他们。同时，要测试一下硬件平台。如果您计划更新硬件平台，一些有关硬件的代码可能会给你制造些麻烦，最糟糕的情况是，您可能不得不重写所有代码。
确保开发人员参与进来，不要假设任何事情。需要认真考虑的事情包括运行时API、系统调用、流和库的支持。确保您完全理解所要移植的内容。这时候你需要评估和核实所有的事情，如应用程序及其库文件和依赖性。您能快速确定产品是否能在Linux上运行和在哪里运行。
毫无疑问，Java程序比C语言程序能更快地移植。此外，在移植过程中，您还需要核实测试环境、用户界面需求、平台可靠性限制、中间件产品和内部技能水平。每一个环境不仔细都可能在未来给您带来麻烦。
应用程序升级
应用程序是移植过程中最重要的一块。在某些情况下，您的应用程序可以直接被移植，但是这种情况很少发生。另一种情况是，您必须在新平台上重新编译它们。移植和编译过程都不复杂，然后需要做的就是测试以确认一切OK。
应用程序的移植过程应该包括开发和测试。在进行移植的时候，您必须有可靠的办法来保证您的数据库正确移植。另外，应用程序所要求的内核扩展和准备驱动，在新的平台上并不一定能够得到满足，因为大多数的内核API并不严格遵循标准。
应用程序是否正在使用第三方组件，如数据库工具、应用服务器或其它中间件呢？如果是，这会增加移植的复杂性。应用程序是32位还是64位？如果是从32位移植到64为，您将不得不付出更多的时间。应用程序如何和数据库通信呢？它们使用数据库接口吗,如ODBC或者编程语言,如C++？这些方面您都需要认真考虑。从人工的角度来讲，尽可能的让那些有各种移植项目经历的人加入您的团队。
稳定性和性能评测
通常在最初的几周内，各种应用程序问题会陆续出现，工程师们会***时间想办法来解决它们。这时候您可能想重新审视您的项目计划并调整交货时间。
测试应用的稳定、功能和性能非常关键。与其花费200万美元开发新系统，还不如花费2000美元测试。测试的顺序通常如下：
迁移工程师对于需要移植的应用程序进行模块测试。
应用工程师执行功能性测试。
用户验收测试(UAT)。该阶段实际的商业用户进行测试。
性能工程师进行性能测试。
在测试过程中，对要迁移的应用程序进行压力测试不可缺少，这样能确保新系统能够应付各种负载。此时，您应该已经完成了基本的测试，并且对于旧环境和新环下的应用程序性能，您该心中有数。
对于稳定性和性能，也需要进行类似的测试。尝试击败你的系统。使用诸如惠普LoadRunner等工具来模拟正常量5倍的负载。
现在是时候来发现Bug了，当然这不是在生产环境上。在进入生产环境之前，您就有机会调试问题。利用测试，不要让使用系统的人来核实是否有问题。业务内容也必须涉及，而且应该有独立的UAT计划。如果您的系统在旧环境上有很高的可用性，那么在新环境下，必须测试高可用性是否继续有效。
