应用通常可以单独转移，但不是无条件的
Play Console 提供应用所有权转移功能，可以把应用从一个开发者账号转到另一个开发者账号，所以「带 App 就必须整号交」不是通用规则。但能否转移取决于具体条件：转出和接收双方账号状态正常，操作者具备相应权限，应用本身没有阻碍转移的状态。具体限制会随平台更新，以 Play Console 当时的帮助页和转移界面提示为准。因此第一步不是问「能不能分开」，而是让卖家在后台确认这个应用当前是否满足转移条件。
先分清买的是应用资产，还是账号本身
应用资产包括包名、已有用户、评分与评论、安装量和更新渠道。账号本身包括注册时间、开发者名称、账号类型（个人或组织）、注册国家，以及账号下积累的历史记录。应用转移只带走前者，不会带走账号年龄，转移后商店页展示的开发者名称也会变成接收账号的名称。如果你要的是老号属性或特定国家的账号类型，单独转移应用解决不了；如果你只要一个已有用户的应用，整号交付反而会多承接一堆不需要的东西。
转移前要逐项核对的五类控制项
一是签名：应用是否启用 Play App Signing，上传密钥由谁保管，转移后能否继续正常发版。二是应用状态：有无政策警告、下架记录或未处理的审核问题。三是收费结构：如果有内购或订阅，需确认付款资料和商家账号在转移后如何衔接，这部分以平台当时说明为准。四是关联服务：Firebase、AdMob、Google Ads 关联、Play 游戏服务、API 访问和服务账号，凡是绑定在原账号上的都要列出处理方式。五是源码与资料：源码仓库、构建配置和第三方 SDK 账号是否一并交付。任何一项说不清，转移后就可能出现无法更新或收入对不上的情况。
这些情况更适合整号交付
账号下有多个应用且彼此共用付款资料或成员权限时，拆开转移的工作量和出错概率都更高。应用不满足转移条件时，整号交付可能是唯一可行方式。买家本身就需要特定国家、特定类型的账号或老号属性时，也只能整号。代价是你承接的不只是应用：账号的政策记录、其他应用、成员权限、付款资料和联系邮箱都要逐项核对，并在交付后重置登录凭据、恢复方式和联系人信息，确保控制权真正在你手里。
这些情况更适合单独转移应用
买家已经有符合要求的开发者账号，只需要其中一个应用；或者卖家账号下还有无关应用要保留，不能整号交出。单独转移还有一个好处：不继承卖家账号的整体历史，风险面更窄。前提是接收账号已完成验证并处于正常状态，且买家清楚转移后应用将挂在自己的开发者名称下。新账号上线新应用时的测试等要求，以官方当时页面为准，不要把它们和已有应用的转移混为一谈。
下单前写进确认单的内容与停止条件
确认单至少包含：包名与应用清单、交付方式（单独转移或整号）、签名与上传密钥的归属、关联服务的处理方式、付款与收款资料的衔接、转移失败时的处理办法，以及交付后的验证步骤。判断标准很直接：卖家能在 Play Console 中展示应用状态、签名设置和关联项，并说明每一项怎么交，就可以继续；只能给截图、说不清密钥和关联服务去向，或回避转移条件的，应暂停下单。发芽提供按国家、个人或组织、是否带已有 App 区分的谷歌开发者账号，下单前建议先把上面这几项对上。
常见问题
应用转移之后，评分和已有用户还在吗？
应用转移的目的就是保留包名下的应用本身，已有用户通常可继续获得更新。具体哪些数据随应用迁移、哪些需要重新配置，以 Play Console 当时的转移说明为准，下单前让卖家在后台核对。
买应用单独转移，能得到老号的账号年龄吗？
不能。应用转移只迁移应用，账号注册时间和历史属于账号本身。如果你需要老号属性，应选择整号交付，并核对账号历史记录。