移动大型机工作负载之所以很难，是因为它们很复杂。最近笔者有机会与Cobol-IT、Compuware、Heirloom Computing、TmaxSoft，以及另外几家公司的代表进行交流，这些公司关注的客户群是仍在使用大型机的企业。有几家公司（比如Compuware）专注于为大型机添加快速应用程序开发和部署（又叫DevOps）技术。
　　而大多数公司专注于说服企业：是时候丢弃大型机了，应该将那些工作负载迁移到运行Windows或Linux的基于行业标准的x86系统上，或者迁移到中档Unix系统上。
　　不管受到行业的关注力度有多大，大型机仍然是企业数据中心的一个常客。关键问题是为什么会这样？
　　大型机工作负载复杂
　　希望迁离大型机的企业面临的一个问题是：它们自己的工作负载带来的“全有或全无”（all-or-nothing）的挑战。这种工作负载相互依赖、错综复杂，以至于要一下子迁移过去，否则企业就会受到影响。
　　问题通常集中于因零敲碎打地添加功能或需要添加新的开发或运维工作人员，以支持目标环境而引起性能欠佳或增加复杂性。最终，硬件或软件方面节省的成本不如混合计算解决方案所需要的成本大。
　　一些公司选择用基于云的解决方案取代全部功能，或者只是将整个定制解决方案换成一款定制性較差的、现成的软件包。在这种情况下，企业决策者似乎接受了以较差的定制性来换取一些好处：通过使用一批基于行业标准的系统来提升性能；更容易找到开发和运维工作人员，或者为可以在行业标准领域找到的额外硬件、软件和软件组件降低成本。
　　笔者注意到，这个“大型机迁移”市场中的许多竞争对手都针对在大型机上执行的基于Cobol的应用程序。一些公司希望说服客户通过将Cobol转变为Java来迁移到其他计算平台或云端，另一些公司建议迁移到更容易移植的Cobol版本，还有个别几家公司建议使用不同的语言处理环境。如果没记错的话，其他那些平台中有一些包括Ruby和Python。
　　虽然所有这些服务似乎至少提供帮助企业停用大型机的某种技术，但没有一家真正着手改善整个环境。
　　迁移的潜在复杂性
　　大型机工作负载常常很复杂，结合了编程语言、工作负载管理工具、事务处理监控工具和大型机数据库引擎。整批工作负载的迁移通常包括找到一种方法，可以一次性取代下列所有的工具：作业控制语言（JCL）文件；事务处理环境监控工具（通常是CICS或IMS TP）；数据库引擎，可能是下列任何单独一种，也可能与另一种结合起来，包括Adabas、CA Datacom、IDMS、Oracle、FOCUS、NOMAD、TOTAL/SUPRA/ULTRA、IBM IMS、Model 204、SQL / DS或另外几种产品；用一种或多种受到支持的大型机语言（将近20种）编写的应用程序。
　　不难看出，将整个工作负载环境从大型机迁移到别处是个很难的问题。这就是为什么大多数供应商将“容易迁移”的部分挑出来作为其关注的卖点。
　　谁能帮助迁移大型机？
　　许多供应商都想方设法引起企业的关注，但是它们真能帮上忙吗？这是个简单的问题，但回答起来很难。这完全取决于该企业的大型机计算环境到底有多复杂。
　　如果这个环境主要由使用关系数据库（由简单的作业控制环境来管理）的一些Cobol应用程序构成，答案可能是厂商可以帮助做好迁移工作。如果该企业的环境比较复杂，那么厂商最多帮助将简单的部分迁移到别处，而对其他部分则不负责处理。