定制开发项目的数据通常存在哪里？如果后续更换团队，会不会被卡住？

结论：定制项目的数据可以存客户自己的云账号、机房，也可以由服务商托管；最稳妥的默认方案是生产数据库、对象存储、域名和关键第三方账号归客户主体所有，开发方使用受限子账号。只要源码、数据、备份恢复、配置和文档完整，更换团队不应依赖原供应商“给钥匙”。

数据“在哪里”包含物理或云地域、由哪个主体开通、谁能访问、如何备份和怎样导出。即使数据库在客户选择的云上，如果主账号、加密密钥、域名或短信支付账户由乙方控制，客户仍可能被锁定。反过来，服务商托管也不必然失去数据权利，但合同必须明确导出和迁移。

在约定交付物、接管方式与责任边界时，还可以对照 源码交付后，我们自己的技术团队能顺利接手维护吗？；这些内容补充了需要放在同一项决策中考虑的上下文。

三种部署归属直接对比

方式	账号与基础设施	优势	主要风险	直接建议
客户公有云账号	客户主账号，开发方子账号协作	资产和账单清楚，迁移方便	客户需承担账号、安全和费用管理	多数定制项目默认推荐
客户机房 / 私有云	客户硬件和网络	数据边界最可控，可离线	部署、容量、备份和运维要求高	监管或网络隔离场景
服务商托管	服务商账号或平台环境	客户启动快、运维省	账号、迁移、费用和退出依赖较高	合同必须约定随时导出和退出

混合云也很常见，例如核心数据库在客户内网，静态资源和公网入口在云上。关键不是追求单一形态，而是画清数据流和责任：业务数据、文件、日志、搜索索引、缓存、消息队列和备份分别在哪里，哪些含个人信息或商业秘密。

防止被卡住需要哪些资产

资产	交接要求
账号与权限	云主账号、域名、证书、应用商店、支付、短信、邮件等归属和管理员清单
源码与版本	完整仓库、分支和 tag、依赖锁文件、构建说明与第三方许可证
数据与文件	数据库 schema、字段字典、全量导出、对象存储目录和数据格式
配置与密钥	环境变量清单、密钥位置与轮换方式，不在普通文档明文泄露
部署与运维	架构、流水线、镜像、启动停止、监控、备份、恢复和回滚手册
外部集成	API 文档、回调、测试与生产账号、配额和供应商联系人

只有备份文件不够，必须在独立环境演练恢复，并记录恢复时间和缺失项。只有源码也不够，数据库、对象文件、密钥和第三方账号缺一项都可能让系统无法运行。数据导出应使用公开或双方约定的格式，并说明大文件、增量和停机窗口。

合同和日常管理怎样做

合同写清数据和代码归属、服务商使用目的、访问人员、留存、备份、导出频率、退出协助、费用、删除证明和违约处理。客户至少保留两名管理员，开发人员按最小权限访问；人员离场或项目结束及时收回。生产数据进入测试环境前脱敏，日志和监控也纳入数据清单。

建议在项目中间就做一次“可移交演练”：由未参与开发的人根据文档拉起测试环境、恢复一份脱敏数据、执行核心流程。这样缺失的脚本和隐性知识会在尾款前暴露，而不是换团队时才发现。

更换团队时先冻结或控制变更，导出代码、数据和资产清单，轮换原团队凭证，再由新团队在隔离环境恢复和验证。对在线业务制定切换、增量同步、停机和回退方案，不能直接把数据库压缩包交给新团队就结束。

滚水科技倾向客户持有生产云、域名和第三方主账号，并按 透明交付标准 约定源码、数据与部署资产。若客户选择托管，我们会在合同中说明导出与迁移边界；不会把“数据属于客户”停留在口头承诺。

参考依据

• NIST Cloud Computing Standards Roadmap：用于参考云计算互操作、可移植和标准化问题。
• The Twelve-Factor App—Config：用于参考将部署配置与代码分离的工程原则。
• 滚水透明交付标准：用于核对滚水科技公开的资产和交接边界。

数据归属与迁移责任最终以合同、账号现实控制权和可恢复证据共同判断。