云计算的主要服务模式包括IaaS、PaaS和SaaS，分别提供基础设施、应用运行平台和现成软件。选型时，它们对应着不同的工作交接范围：租用云服务器后仍要维护系统，购买在线软件后也仍要管理账号和业务数据。

公有云、私有云讨论的是部署方式，与这三种服务模式属于不同维度。判断产品属于哪一类，要看它交付什么，以及服务商负责维护到哪一层。

只想使用现成软件时，先看功能和数据出口

如果需求是让员工直接使用客户管理或协作软件，SaaS往往进入采购范围。服务商维护应用及其运行环境，企业通过浏览器或客户端使用，无须自行安装服务器操作系统。

采购中的误区，是把“开通即可使用”理解成所有工作都已交给服务商。员工离职后的账号关闭、业务数据的访问权限，仍由企业安排。服务商负责软件运行，不会自动判断某个员工该看哪些客户资料。

遇到现有流程与软件功能不匹配，先核对配置能力和接口支持。配置能解决的差异不必开发；涉及特殊业务逻辑时，则要确认产品允许怎样扩展。合同到期前的数据导出也要问清楚：能导出什么、采用什么格式，直接影响后续迁移。

自建应用迁移时，平台能接住多少工作

已经拥有自建应用，选择往往集中在IaaS与PaaS之间。

IaaS提供云服务器等基础资源。团队能够控制操作系统和软件安装环境，也要承担系统补丁、应用部署等维护工作。PaaS把更多运行环境交给服务商管理，开发人员按平台规则部署代码；但运行时版本和扩展方式受到产品支持范围的约束。

两者的差异会在迁移过程中显现。服务器控制权较大，意味着团队有更多调整空间；平台代管的工作较多，也可能要求应用改变原有运行方式。

例如，在一个假设的迁移场景中，团队准备把自建订单系统搬上云，希望减少服务器维护。整理部署清单时发现，系统依赖一个必须安装在操作系统中的扩展组件，而候选PaaS不开放相应安装权限。业务代码尚未改动，原来的部署方式已无法直接沿用。

团队把这个组件的用途单独列出，核对平台是否提供可替代的能力。如果替代方案要求改写关键代码，就把改造工作与原有运维投入一起比较。在这个场景中，团队暂时选择IaaS，保留现有运行环境，同时明确系统补丁仍由内部人员处理。

后续安排没有因此全部完成。团队还要测试替代方案与现有应用的兼容性；在确认之前，这部分应用继续保留原有部署方式。

报价放在一起时，把留下的工作算进去

服务模式的名称无法直接回答哪一种更便宜。IaaS账单主要体现所租资源，内部维护投入未必出现在云账单上；PaaS可能减少部分运维工作，但应用改造和平台配套服务也会产生费用。SaaS则要核对账号数或功能版本对应的收费规则。

比较报价时，把业务范围保持一致，再写清交付后由谁处理故障、谁恢复业务数据。云服务器运行正常，应用仍可能无法访问；平台承担底层维护，也不会自动修复业务代码中的错误。

拿到候选产品后，核对合同中的维护范围。自建应用补齐依赖清单，验证平台支持情况；现成软件则确认数据导出内容，并用导出样例检查下一套系统能否接收。