很奇怪的是，在经历了十多年的云迁移行业经验后，我们仍然觉得有必要大声呼吁云升移；一种将云简单地视为托管解决方案的实践，导致在云中复制现有架构、安全实践和IT操作模型。这并没有实现云的敏捷性和数字创新的承诺。云迁移需要跨多个轴向云原生状态进行有意的更改，并且根据独特的迁移环境，每个组织可能最终会从云提升到云原生状态。例如，系统架构是交付敏捷性的支柱之一，并且经常需要更改。简单地将现有系统提升和移动为集装箱要云可以强。虽然这种策略可以加速云迁移，但在创建敏捷性、交付特性和价值方面还不够。云中的企业安全与传统的基于边界的安全(通过防火墙和分区)有着根本的不同，它需要一个通往边界的旅程零信任体系结构．IT运营模式也必须进行改革，通过自助自动化平台安全地提供云服务，并授权团队承担更多的运营责任和获得自主权。最后但并非最不重要的一点是，组织必须构建一个基础来支持持续的更改，例如创建管道，并将应用程序和基础设施的持续测试作为迁移的一部分。这将有助于迁移过程，产生一个更健壮、更合理的系统，并为组织提供一种继续演进和改进其系统的方法。
随着越来越多的组织选择在云中部署应用程序，我们经常发现IT团队浪费时间试图在云中复制他们现有的数据中心管理和安全方法。这通常以防火墙、负载平衡器、网络代理、访问控制、安全设备和服务的形式出现，这些设备和服务无需重新考虑就可以扩展到云中。我们已经看到一些组织在云提供商面前构建自己的编排api，以约束团队可以使用的服务。在大多数情况下，这些层只会削弱功能，带走迁移到云的大部分预期好处。在这一期的雷达中，我们选择了重亮云升移作为一种避免的技巧。相反，组织应该更深入地研究其现有安全和操作控制的意图，并寻找在云中工作而不会产生不必要约束的替代控制。对于成熟的云提供商来说，这些控件中有许多已经存在了，采用云的团队可以使用本地api来进行自服务的供应和操作。
随着云应用的增长，不幸的是，我们看到了一种趋势，即把云当作另一个主机提供商。云升移不幸的是，大型供应商将现有的主机产品重新命名为“云”。它们很少提供任何真正的灵活性或按使用付费定价。如果您认为无需重新架构就可以迁移到云，那么您可能做得不对。
