编者按：本文是发表在SearchEnterpriseLinux.com上的关于UNIX迁移到LINUX的系列文章的第四篇。第一篇是关于在功能丰富的Linux面前Unix所面临的挑战，第二篇是Linux在支持业务系统方面的发挥，第三篇是关于Unix上的应用向Linux过渡。

　　从Unix向Linux迁移所要做的第一个步骤就是准备好一个测试环境。你的团队可能缺乏Linux的相关经验，有一个测试环境用来学习是非常必要的（不用担心误操作破坏任何东西）。

　　让我们来讨论以下代码和程序。你的系统运行JAVA还是C语言？是否存在什么第三方的工具需要迁移？它们是否能迁移到Linux上？

　　假设你用的是C语言。再假设你有一些代码需要迁移到LINUX系统上去。建议使用GNU（gcc）程序，因为它符合工业标准，是Linux下天生的编译器。用其它平台编译的程序将需要重新编译一次。

　　关于编译你的业务代码有两种方法可供选择。第一个方法是在你已有的环境中进行编译，这种情况下你要准备好所有需要的工具，包括源代码和编译好的文件。如果你考虑这种方法的话，务必在你的测试环境中进行，千万不要在生产环境里做。

　　另一个方法是将你的所有数据和代码都移动到新环境里，然后用原型环境来运行进行测试。这种情况需要考虑硬件平台。如果你计划迁移硬件平台，也许有些和硬件相关的代码会有麻烦，最糟糕的例子可能会迫使你重写代码。

　　在迁移过程中，务必确认你的开发人员也参与其中，并且不要假设任何事情。充分考虑包括API，系统呼叫，streams和库支持等方面因素。确保你完全明白你的目标。这些因素是你在实施之前做评估以及确认所有和应用相关的库和依存关系的关键所在。用这种方法可以让你迅速确认在新的LINUX环境下哪些产品是可用的以及在哪能找到它们。

　　毫无疑问的，用JAVA编写的程序相对用C写的程序来说，迁移起来要快速一些。除了你的应用程序之外，你还需要确认测试环境，用户界面需求，平台依赖限制，中间件和内部的技术水平。每一个方面都存在一些风险。

　　升级应用

　　升级过程中最重要的部分就是应用程序了。在一些案例中，应用被很容易地迁移到新系统中，也没有额外的工作需要做。而在另一些案例中，你不得不在你的新平台中重编译它们。迁移软件有时在重编译完程序之后就完成了，然后就是运行验证测试来确保一切都没有问题。

　　迁移过程应当包含开发和测试。当你迁移你的系统时，请首先确认你迁移数据库所要采用的方法。那些需要内核扩展和驱动程序的应用不太容易实施，部分原因是大部分内核API都不是按严格标准来设计的。

　　应用是否采用了第三方的软件组件，比如数据库工具，应用服务或者其它中间件？这些会增加迁移的复杂性。应用是32位的还是64位的？如果你要将32位平台迁移至64位，你将花费更多的时间来实施。你的应用如何和数据库通讯？它使用如ODBC的数据库交互界面或者如C++之类的编程语言吗？这些因素你都应该充分考虑。站在一个员工的立场，尽量让有这方面项目经验的人来实施会比较稳妥。

　　检验稳定性和性能

　　应用问题一般在运行的头几个星期就会被发现，工程师在这个时段会对即将面对的问题有个模糊的概念。这时你也许会想再重新复核一些项目计划来调整交付日期。

测试对验证稳定性非常重要，包括功能和性能。不要花费了200万美元开发一个新系统之后只愿意再花两千美元用来测试。测试的顺序一般如下：

1. 负责迁移的工程师进行应用的模块测试。
2. 应用工程师进行功能测试。
3. 然后是用户验收测试，或者简称UAT。这时有真实的系统用户来进行的测试。
4. 性能功能是进行性能测试。
5. 在测试过程中，本质上迁移的应用是在压力环境下进行测试，这样以确保系统能处理相应的负载。你应该完成基本测试，它们都是在你现有的生产环境下进行以获取性能快照。
6. 你的目标是以稳定性和性能为导向进行的相似的测试。尝试攻击你的系统。利用一些如惠普的loadrunner等的工具来模拟5倍于常用操作产生的系统负载。
7. 接下来是找出漏洞－在迁移到生产环境之前就要做。你应该在它们迁移到生产环境之前抓住机会调试程序从而找出问题所在。利用测试过程，另外不要只是让你的系统管理员们来验证系统。公司里业务部门的用户不仅应该参与进来，而且应该加入用户验收测试计划的编写。就算你的系统在旧环境中非常稳定，也仍然要确认它们被充分测试。