假设一种情况：用户需要用到他们大型机上的某项应用，但是厂商却不能再提供服务支持。比如以前负责升级该应用的某个开发人员/管理员离职了，或者公司决定停止对升级服务的继续投入。那么，替代方案是什么？在这里，我们将介绍几项应用迁移的策略及各自的优缺点。例如应用现代化、重组、分布集成。

一般来说，可以替换掉应用（希望好能这样），改用能够支持的语言/操作系统/平台。或者直接把这个应用当作“黑匣子”，在它下面建立一个独立子应用处理所有升级需求。后两个策略使用到下面这些广为人知的技术：

1.大型机应用现代化：在应用前端设置一个网页服务供应商接口，用以处理所有与该应用发生的交互活动。

2.重组：利用应用的原有功能，在另外一个平台上把它转化为相应功能。

3.分布集成：分配众多子系统在多虚拟机和物理机上运行，使它们犹如一个整体在运转。

我们应该把正反两方面意见，把策略和技术上难点都纳入考虑范围。

一、更换应用

理想情况下，应用更换在任何时候都是最棒的替代方案。只要想象一下，新应用能够神奇地出现在对你来说最省成本的平台上并能正常运转，不需任何花费，而且能准确复制大型机上已有的应用。而现实世界中，应用更换通常是最糟糕的替代方案。现成的成套应用方案无法模拟现实应用，这让终端用户很恼火；但从零开始研发成本太高，不仅会占用主要的IT项目，而且常常会因为对现有应用的功能知之甚少，且少有记载导致失败；而且，替代方案实施失败的话，也没有所谓的B方案可供选用。

众多成功的应用更换在牵涉到“关键业务大型机应用”时，采取的都是“足够好”的办法。也就是，把重新开发工作外包给一家兼具大型机和替换平台（通常是linux）专业知识的应用迁移公司。他们使用的基础软件是经过时间验证的（不管是不是开放源）。他们关注旧大型机应用的主要功能，并尽其所能减少新应用可能带给用户的不便感受。而且采用了“平等追踪”的部署方式，能够确保只有在新应用“服役”满一年后旧应用才正式“引退”。

与直觉相反，针对上述替换方案现今好的目标操作系统，可能经常是“大型机上的Linux”。这里提到“Linux”是因为，它能根据需要，只作最小的应用修正（大型机Linux与大型机、放大Unix和扩容PC服务器稍有不同，但新应用完全能写成便携方式）就能允许对平台的进一步变更。而这里提到“大型机”的原因则是，直到现在，许多用户仍反映大型机处理应用扩容最节约成本。一位技术执行官最近跟我说到了他的认识，他发现一台大型机负载达98%但仍有处理冗余，而一台扩容服务器负载只不过50%时但让人感觉后劲全无。这仅仅意味着扩容应用在大型机上运行较节约成本，因为如果在扩容配置中增加常规服务器花费很大。

二、转换与分布集成

应用现代化

大型机应用的持续现代化，也包含了对网页浏览器的支持，以及对PC访问和网页服务供应商界面的支持。但实际上，许多应用还未达到现代化标准，无法支持此类网页，这其中可能就包括了你的应用。多数大型机软件供应商针对此类问题有许多应对工具和服务。不论客户是想在迁移应用前，还是在应用迁移到新平台后，他们都能够帮助达成添加网页服务供应商界面这一目标。对于哪种是最佳的应用迁移方法并无定论。但是对大型机应用结构和操作了解的越多，就越容易将其封装成“网页服务供应商”。

人们常常低估了大型机应用现代化的效用。不过，应用迁移负责人要明白，如果想要建立内部云或者使用外部云平台，除非大型机应用已经被转化成网页服务模式，否则它在云平台上是不可用的。如果应用被虚拟成网页服务形式，那么从长远来看，云平台的施行是再简单不过的事情了。

重组

如果能够对应用本身进行提取程序模型（确定程序实际运行方式），那么重组对于应用迁移来说就是一个好方法。对大型机应用进行重组的副作用通常是出现一个标准化模式，允许在开发设计阶段（例如UML）进行修改。这类提取不仅允许生成面向所有主要编程语言和环境（例如，所有平台上的Java）的应用实例，而且使得程序的修改和升级变得更容易。它不是对应用本身进行修改，而是通过修改设计来达到目的。

因此，“重组专家”的主要任务是利用IBM，CA Clerity公司和Micro Focus公司这类厂商的重组工具生成一个适合企业现有开发流程的标准模式。从而确保今后企业若想把应用迁移到另外的平台，或是计划对其进行现代化，扩展或合并时（例如，使其成为复合应用的一部分），此类操作会更快捷和更安全。

分布集成

分布集成是关于让大型机应用（作为“黑匣子”或转型应用）在两个或两个以上的目标平台运行的理念，就像IBM的zEnterprise（Linux在刀片上，也在大型机系统上）。对于“黑匣子”型分布集成，使用z/OS或大型机Linux作为其中一个平台以减小平台移动的风险通常是有道理的。然而更具典型意义的是，分布集成涉及到的是向两个平台迁移而不是一个，不过平台之间（例如，虚拟机管理，网络和调度）的集成工具使得实际中对产生的子应用的集成变得更简单。

分布集成取得成功的关键在于争取到一个能使应用性能大化的目标应用分布。比如，一个能从放大中受益的应用，要尽可能把重负荷放在放大服务器上处理（放大或大型机Linux），并利用应用的扩容元件执行“边缘”任务，例如缓冲。扩容型应用则应把多平行复本放到网格型或刀片型网络中的多重虚拟机上，同时把不易发生故障的放大机作为管理重点。

很多应用属于zEnterprise方案的“折衷”版本，分别由放大和扩容来处理各自擅长的部分。在这种情况下，用户要寻求跨平台管理工具的大化支持。我们可以看到，通过一些努力，现在有可能让Windows成为目标平台之一——通过在z/OS上安装Windows模拟器，以“黑匣子”方式部署或重新编译Linux版本以兼容Windows（需要重新编写多达20%的原代码）。

分布集成的另一个关键任务是建立随时可以与其它分布应用进行分布通讯和集成的应用。这点经常被错误理解为在各应用之间建立起标准化通讯。实际上，分布集成的主要目标是要建立起应用之间数据交换的标准化方式——更具体来说，要界定应用里的元数据并使其涵盖进全球元数据池。然后，类似ETL和IBM‘s Information Server的数据合并解决方案就可以利用这些数据掌握数据管理，跨企业报告等等。

转换

就像前面所指出的那样，转换就是要改变现有大型机应用的代码，以使其能适应在不同平台上运行和升级。因此，转换的目标是尽可能少作变动，尽可能自动化运行。也许还需要把它分解到多平台上，或是在转换过程中进行升级以便支持复合应用或适应更高级的云和网页功能。

有三种基本途径可以对此类大型机应用进行转换：

1.建立一个包含基础软件型目标平台的目标环境，并重写不受支持部分。例如，依赖CICS，MQSeries和DB2的大型机COBOL应用可以利用厂商的转换程序，虽然要重写交叉汇编码。可以从厂商和Clerity Solutions这样的应用迁移外包商那里获得Linux基础支持。

2.上面已经介绍过大型机应用重组。这里补充一点，虽然应用迁移外包商在这方面做得越来越好，但是也存在一些情况会让他们感到无能为力或困难重重。

3.根据需要逐项重新编写应用。经验表明，这很可能与更换应用一样冒险，甚至代价会更大。无论如何，对于业务关键性应用，这可能是好的选择了。

从长远看，应用重组可能是好的方案。因为应用重组从根本上对代码进行了现代化处理，使得对应用的进一步变更有更大灵活性。在上述三个例子中，转换应用时，使应用现代化无疑是个好主意。因为类似的用途会是网页型组织的一部分，甚至可能是云平台的一部分。分布集成是可以自由选择的。许多案例可以证明，要把转换过程包含在分布集成内将会过于复杂。