并非每个遗留应用都与云服务兼容。了解任何给定应用程序的最佳路径——这可能是成功与失败的区别。

负责遗留应用的管理员可能会被云原生应用的繁荣所影响，但即使是很小的更改也可能将遗留应用引入云资源。

IT设备供应商和其他批评者提及云上的失败时通常会说——糟糕的性能、不稳定的应用行为、爆炸式的成本——他们散播恐惧、不确定性和对遗留应用迁移到云的怀疑。但是，Amazon Web Services（AWS）和其他供应商的持续成功，淹没了公有云无法处理企业系统的说法。例如，美国航空公司将其一些最明显的应用程序转移到了IBM的云上，通用电气公司关闭了数十个数据中心，将数千个应用移动到了AWS上。

云基础设施即服务（IaaS）产品（如AWS弹性云计算（EC2））只是一种迁移目的地。其他公司使用的SaaS产品克隆了传统ERP，客户关系管理（CRM）和其他系统的功能。例如，Oracle和Salesforce都向大公司示好，将流程和管理迁移到其SaaS方案中。

当评估要迁移的应用类型和要采用的云服务类别时，请保持开放的态度。查看云服务的层次结构，了解某些应用程序类型对某些服务最为有效。

IaaS非常适合于虚拟机基础架构，包括SQL和NoSQL数据库以及基于开源平台的自定义应用程序。

Web应用程序，移动或物联网应用的后台、自定义Java和其他业务应用都是迁移到平台即服务（PaaS）的良好目标。
SaaS更有利于业务线系统，如CRM和ERP，或生产力、通信和协作服务。

现代技术

遗留应用的成功迁移与执行它们的组织一样独一无二，但通常都属于升级转换和重构类别。前者几乎不需要对底层应用进行任何更改，而且整个过程持续时间较短，但这并不能让其最有效地使用云服务。

IaaS方案（如Amazon EC2，Elastic Block Store和Simple Storage Service）本质上是云版本的虚拟机、存储卷和网络文件共享，并与虚拟化应用兼容。升级和转换迁移通常将Linux或Windows应用镜像移动到云虚拟机（如EC2或Microsoft Azure VM）上，并且不进行任何代码修改即可运行。为了简化这种遗留应用程序的迁移，请使用镜像和数据迁移自动化软件。诸如CloudEndure、Zerto、Carbonite DoubleTake和Racemi等产品在后台执行连续数据复制，最大限度地减少了从传统基础设施到云端的停机时间。

与在私有VM服务器上不同，企业无法无限制地选择部署在云实例上的操作系统版本。例如，虽然Azure支持Windows Server 2003及更高版本，但用户需要的版本比Windows Server 2008 R2还要早，而且无法从Azure Marketplace下载任何预先测试过的镜像。对于Linux镜像来说，情况要好一些，AWS、Azure和Google Cloud Platform提供各种发行版和配置。

像Azure Web App Service或Google App Engine这样的PaaS适用于以支持的语言运行的应用，例如Java，.NET，Node.js或Python。这些都提供运行时引擎和执行环境，通常包括自动缩放，负载均衡，健康检查与自动应用重启和应用版本回滚等功能，将用户从底层基础架构中隔离出来。

商品应用的遗留迁移——电子邮件服务器，协作应用程序（包括SharePoint或Web会议工具，CRM和ERP）是最容易使用SaaS产品的。企业应用的SaaS版本通常通过订阅来提供最新版本，包括持续更新、安全检查、容量扩展和性能监视。大多数组织都可以将用户转移到SaaS后端，尽可能地减少中断，如果公司没有大量定制应用程序的配置，则没有数据丢失。

现代化和重构

为了使遗留应用真正地具有云友好性，需要对单一应用架构进行模块化，以使其更容易地使用本地云服务。对于不能重构的应用，例如商业现成的软件，升级和转换的迁移方法是必需的。可以重新设计的内部应用，即使是相对较小的修改，例如代码重新分配，也可以实现性能改进和成本降低。例子包括数据库和业务逻辑功能分离，以便应用程序可以使用PaaS托管服务（如AWS Relational Database Service，Azure SQL AWS Relational Database Service或Google的Cloud SQL），或分离单一代码为能够在容器服务上运行的独立模块 （例如AWS EC2 Container Service 或Google Container Engine）。