云计算常见的三种服务模型是IaaS（基础设施即服务）、PaaS（平台即服务）和SaaS（软件即服务）。区分它们，主要看你购买的是计算资源、应用运行平台，还是已经做好的软件，以及交付后哪些事情仍由自己处理。

只想直接使用软件，先看SaaS能否满足业务

打开浏览器登录在线办公或客户管理系统，不必自己安装服务器软件，这类使用方式多属于SaaS。服务商维护应用及其运行环境，用户通过账号、订阅和配置使用功能。

采购时，判断往往落在具体操作上：现有业务流程能否在软件中完成，积累的数据能否完整导出。若关键流程只能依靠服务商排期开发，订阅后仍可能受到限制；导出文件若缺少附件或关联关系，后续迁移也会增加工作量。

SaaS省去了大量底层维护，但企业账号权限和业务数据管理仍由用户承担。员工离职后停用账号、限制敏感资料的访问范围，都不会因购买了云服务而自动完成。

要部署自己的应用，比较IaaS和PaaS接手到哪一层

IaaS提供虚拟服务器、存储等基础资源。拿到云服务器后，团队自行安装运行环境、部署代码，也要维护操作系统和应用。服务商管理底层基础设施，并不代替用户修复自行安装的软件。

PaaS将应用运行平台交给服务商维护。开发人员按平台支持的方式提交代码或应用包，减少操作系统层面的维护工作。不过，平台支持哪些运行环境、允许怎样配置，会直接影响现有程序能否部署。托管程度不同，双方承担的任务也有差别，具体以产品说明为准。

因此，对操作系统配置有明确要求的应用，使用IaaS能保留较多控制权；符合平台运行规则、团队又不想长期维护底层环境的应用，适合评估PaaS。

费用也沿着这条责任分工展开。IaaS账单之外，还要安排补丁更新和故障处理；PaaS减少部分维护工作，却可能增加平台费用或应用改造投入。只比较页面上的起步价格，会漏掉这部分长期成本。

现有程序依赖系统组件，迁移方案怎么定

假设一个小型开发团队准备把现有网站迁到云端，希望采用PaaS减少维护工作。梳理部署脚本时，团队发现程序启动前要安装一个系统级组件，而拟选平台不允许用户修改底层操作系统。代码能够上传，原有的启动方式却无法直接沿用。

此时，迁移判断落在这个组件上。若平台已有受支持的替代能力，团队就修改调用方式并验证功能；若组件无法替换，继续使用云服务器部署，也是一条可行路径。不能仅凭“PaaS省维护”就确定方案。

在这个假设中，团队暂时保留原有组件，转向IaaS，同时明确服务器补丁和应用更新的负责人。这样减少了本次迁移的代码改动，但日常维护仍要自己承担，人员安排尚未解决时，迁移计划也不能只写上线日期。

后续测试围绕这一依赖展开：核对组件能否在目标云服务器环境中安装，验证应用启动及关键功能。上线前，再把操作系统更新和故障处理的接手人写进维护安排。至于以后能否转向PaaS，留待替代组件验证后再决定。