假设一种情况：用户需要用到他们大型机上的某项应用，但是厂商却不能再提供服务支持。比如以前负责升级该应用的某个开发人员/管理员离职了，或者公司决定停止对升级服务的继续投入。那么，替代方案是什么？在这里，我们将介绍几项应用迁移的策略及各自的优缺点。例如应用现代化、重组、分布集成。
一般来说，可以替换掉应用（希望***能这样），改用能够支持的语言/操作系统/平台。或者直接把这个应用当作“黑匣子”，在它下面建立一个独立子应用处理所有升级需求。后两个策略使用到下面这些广为人知的技术：
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.根据需要逐项重新编写应用。经验表明，这很可能与更换应用一样冒险，甚至代价会更大。无论如何，对于业务关键性应用，这可能是***的选择了。
从长远看，应用重组可能是***的方案。因为应用重组从根本上对代码进行了现代化处理，使得对应用的进一步变更有更大灵活性。在上述三个例子中，转换应用时，使应用现代化无疑是个好主意。因为类似的用途会是网页型组织的一部分，甚至可能是云平台的一部分。分布集成是可以自由选择的。许多案例可以证明，要把转换过程包含在分布集成内将会过于复杂。
#p# 三、“黑匣子”分布应用
应对撤消大型机应用支持，“黑匣子”方案并不是一个理想的长远解决办法。它会加大应用再变更的难度，但它却是风险最小、最省成本的办法。基本思想是，不触动应用本身，但要用网页服务供应商界面把应用包围起来，使得在开发人员，管理员和终端用户看来，它就像Linux或Unix应用一样在运行。需要升级时，界面会把终端用户需求转化成新代码并交付给新平台来处理。
这个办法行得通的原因在于，在现实世界中，从现在起，即使不是全部亦是大多数大型机应用漏洞将会成为调整的问题，远超出以前的麻烦程度。网页服务界面处理这类问题的办法是暂缓需求处理，重写功能代码。这么做肯定会造成问题，所以这不是一个优越的执行方案，存在自身风险--假设问题被解决了，然后又发现那并不是最糟糕情况--但是精心做的话，它却是快速节约的实施方案，风险也极低。
从定义看，“黑匣子”分布应用实施包括，应用现代化（供应商界面），分布集成（供应商界面代码和新平台的新代码，但是“黑匣子”在老平台上），但并不包括重组。这意味着大型机环境要有网页服务供应商界面的开发支持和跨虚拟机网络和管理--现在多数大型机环境都具备这点，在机箱外。所以，如果把大型机型Linux作为新平台，可以自己动手操作，也可以从IBM获取一点帮助。当然，所有其它环境也同样支持网页服务供应商界面，虚拟机，跨平台网络和开发；只不过，跨平台管理可能要多花点力气。
成本低的缘故，自己动手安装“黑匣子”的想法很有吸引力。但是，预算足够的话，我还是建议把活外包给IBM，CA Technologies，或Clerity这样专业的公司。即使这样，还是比其它方案来得省钱。这些公司凭借与其它IT大型机应用长期打交道的经验，了解难点在哪里，所以能给出诸如该类型应用架构未来可能出现的漏洞之类有价值的建议。这些建议对于业务关键性应用可以说是无价之宝。
大型机应用现代化的现实情况
关于上述所有的策略还有一则警示：代码转移到新平台，意味着性能损失。损失可能不大，就像“黑匣子”方案中出现的；损失也可能很大，遭遇到重新编写多数甚至全部代码的情况。但经验表明，很少出现新应用一开始就在新环境出运行顺畅的情况。
那么该如何在这些策略中做出选择呢？首先，剔除那些不可行选项。很多情况下，无法做到有效替换。有时候，代码过于定制化或无法渗透，那么根本不能进行重组。这时，你要问问自己这个应用到底有多重要，撤消支持的需求有多急迫。对于不是特别关键的应用，如果时间允许的话，重组或者别的形式的转换可能正是需要的手段。如果需求很急切，“黑匣子”可能是唯一出路。
只有到这个时候你才需要考虑费用。这是因为现实生活中经常出现这样的情形，“要么现在付钱，要么回头多付”。初期投入最少方案似乎很有吸引力，例如根据需要逐项重写应用，或是直接启用号称能起到同样作用的新型开放源应用。但是据调查，很多项目都是由于终端用户对于新应用，及伴随出现的停机时间和无法修复的故障等情况产生了极大不满而最终失败。所以仔细权衡承担的风险和后续将产生的维护费用后再做出合理的初始投入决定才是明智的。
***一个忠告：一些把大型机应用重新配置到新平台的应用迁移项目从长远看确实是值得的。通常是因为，网页服务供应商界面允许大型机代码在复合应用中得以重新使用，或者重组让终端新用户能够获取所需功能，而代码也能为新应用所用。所以不要把应用迁移看作逃不掉的苦差事，像人体的牙根管。它也可能是沙子里的钻石，蕴含着优秀的潜质。
