怎样将数据中心现有的物理机和虚拟机平滑的迁移到云平台上？风险和工作量怎样评估？成熟的产品怎样选型？

传统行业上云痛点分析
传统企业上云会有一些痛点，大致分为以下几个层面。
用户体验方面的考虑。可能因为业务过去的包袱太重，导致他们迁移上云会涉及到部分代码层面的修改、打包、重发布、应用管理方式等变化，这会有一定技术门槛，使得迁移上云有一定难度。比如企业软件上云，过去企业的开发人员都是使用传统的开发模型和开发工具做开发，而在云上，很多应用的开发直接就是基于云原生应用架构进行开发的用户体验。这就好比一个使用 WindowsXP 的用户，突然要他去马上适应 Windows10——过程类似，体验不同。在云上，开发工具和开发理念不同，云原生应用开发会将应用的每个部分都打包在自己的容器中，动态编排，以便每个部分都被主动调度和管理，以优化资源利用率和面向微服务的应用程序，从而提高应用程序的整体灵活性和可维护性。如此便捷轻度的开发体验，是原来传统的开发模式所无法达到的。当然，云原生应用给拥有多年传统企业开发经验的开发人员也带来不少的学习成本，在一定程度上打破了他们固有的开发习惯和开发方式，这对于企业业务软件上云，也带来了不少的门槛。我相信，随着整个行业不断的发展，企业的 IT 管理人员、开发人员，能够有更多机会体验到新技术带来的效率提升、应用开发更灵活，大家慢慢用起来，这种现状就可以得到改善。
数据安全方面的考虑。比如说他可能担心数据放在公有云上数据本身是否安全？数据的请求与控制、访问与授权，数据防泄露等安全谁来保障？其实客户的疑问是可以理解的，当然，公有云厂商也提供了诸多的技术保障了数据安全，比如说我们客户的核心业务系统，他的数据要放到云上去做灾备，就涉及到很多技术，比如使用加密技术传输数据。使用密钥技术来加密数据，数据的访问需要客户自主的、多因素的认证，即便是公有云厂商，自已后端的 IT 管理人员，他也没有办法看你的数据。另外，云上数据可以在多个不同区域间进行多副本存储，避免了单一云区域离线后，数据无法请求的问题，在我看来，云上数据安全是有保障的。只不过，用户可能始终会有一种感受，好像数据不在自己家里心里不踏实的那种感受，随着越来越多的用户接入云，大家也在适应云计算技术优势，慢慢相互建立信任的过程。
历史包袱方面的考虑。比如有一些用户过去筹建自己的业务系统，都是烟囱式或者叫孤岛式的。今天我要上一个 XX 应用系统，找一个厂商过来，好，系统上线；到了明天，我又上一个系统……慢慢，系统越来越多，但是，这些个系统之间没有去把数据全部打通，业务流程流转仅限于几个主流的企业应用，长期下来，你会发现一个大的企业里面可能有上百个小业务系统，其中打通的只有那么几个。这时候因为前期孤岛式的业务筹建方式，如果要上云的话，就需要花大量的时间去梳理不同业务逻辑间的关联性、前端和后端的关系，或者是说，从上帝视角来看这些业务如何重新进行顶层设计，这是很多企业面临的的痛点。所以，公司的业务如何在一个全面，有一定高度的方向和基于新平台正确的应用架构设计方式去做设计，是非常重要的。
关于企业上云，虽然有痛点，但办法总比问题多，我们也有非常优秀的云厂在提供好的平台和技术来解决这些问题，也有类似我们这样的云服务合作伙伴一直在努力帮助客户去消除这些痛点，前方一片光明，我们都在路上。

传统企业数据中心向云数据中心迁移的优势
传统企业的数据中心，都是标准化的三层架构（主机层、网络层、存储层）。这种架构经过多年的企业业务的检验，其实也是较为稳定可靠的架构。当然，这是相对于过去的情况而言，因为过去企业的业务可能只是企业内部，在大部分的情况下，访问人数不多。不过仍然有一些大型集团公司的业务会面临并发访问的压力。例如，在某个工作时间，所有人都要去访问 OA 系统查看内部公文、收发电子邮件等。
在传统架构下，比如 X86 的服务器，作为一个计算资源，有节点内部的瓶颈，南桥与北桥的交互，CPU 与内存的交互，磁盘 IO 性能的吞吐。也有节点外部的瓶颈，比如服务器速度很快，但网络如果是千 M 或者是万 M，数据交互经过一层层网络设备中转，有大量的延迟响应；比如你网络是 25G 或者是 100G 快速网络，但你的存储机头是有性能极限的，如存储机头的 CPU、内存、IO 控制器、存储缓存高低等，都会成为传统三层架构中，出现木桶原理中的那个短板……
说到底，传统数据中心的设计，并非是为大规模高并发的应用场景去设计的，很难承载较大的并发访问压力。
例如，云计算中心的后台，X86 架构的计算能力，从主机层面开始就是定制的机器，并非市面通用的 X86 2U 或者是 4U 服务器。这种云计算后端的主机通过一切可能的定制，优化减少各类接口和提高总线间访问速度，精简流转过程，提高数据端到端的交互速度，通过融合架构的方式实现分布式计算、存储等。
大量分布式软件定义的技术，实现网络的高速通道，存储亦是直接就是分布式存储管理系统、分布式文件系统、分布式调度系统等，专为密集型高并发业务场景而设计，并起到很好的集约化效益，为企业用户节省成本。
通过将企业线下数据中心与云上数据中心打通，实现业务数据级灾备或者是应用级双活，可以更灵活的实现业务的多重保护。
而基于云计算构建的云上数据中心，显然有更多的优势凸现

首先要有一个正确的理解，你要迁移不是几个虚机和物理机，而是一个或者多个应用系统。这样这个问题就回到正轨了。
1、应用系统上云，先要对应用系统对一个评估，看是否具备上云的条件，比如应用的架构，是单体架构还是分布式架构，应用运行环境，小机还是X86还是虚机，应用的资源占用情况，应用对资源是否有特殊需求，比如机密狗或者特殊硬件等等，需要对应用性能做一个周期型监测和评估；
2、如果是小机势必会涉及应用改造的问题，需要跟应用开发商沟通，评估代码迁移改造的可行性和对性能的需求，然后再进行迁移上云；
3、如果是物理机，则需求对应用系统的性能需求进行评估，一般一台物理机需要折算成若干台虚拟机的算力，在云环境里面需要做一个架构设计，需要SLB等组件的配合，还有评估应用系统是否支持无状态部署，如果不支持，也得做无状态的改造；
4、如果虚机，需要评估原系统虚拟机镜像的直接迁移的可行性，是否兼容等等
5、至于具体如何进行迁移的实施，又得分若干情况，如果应用可以停机迁移，那是做踏实的，直接做就行了，如果非得在线热迁移，那就比较麻烦，只能用工具。
6、一般来说，如果是公有云，或者主流大厂的云平台，他们都有原厂的迁移工具，可以很好的利用，第三方的比如英方，也提供第三方迁移热迁移工具，都可以试试。
保险起见，建议找一个提供msp服务的云服务商去帮你做这些工作。