摘要

  • Google Cloud 项目迁入新组织后，原 Cloud Billing 账户继续付款；组织归属、有效权限和供资关系分别变化。
  • 直接从 Cloud Marketplace 购买的活跃订单，转移账单账户需要客户与独立软件供应商同意，可能花一周或更久。
  • 转移期间在目标账单账户向同一供应商购买产品，会使订单转移无法进行。交接计划必须安排采购的先后顺序。

公司分家，最漂亮的交接证明可能是一张截图：项目已出现在新公司的组织树下。Google Cloud 的规则会给这张截图补一张小票——原账单账户仍在付款。

这并非后台漏改了一行。Google 的项目迁移说明明确把两件事分开。迁移更改项目的上级组织元数据，项目 ID、编号、数据和资源保留，直接授予项目的 IAM 角色也保留。账单账户仍是原来的那个。一个项目可以在新组织名下，由另一个组织的账单账户供资。

因此，业务部门说的“交过来了”，至少有两种含义。工程团队可能已经拿到新的管理位置；财务关系却仍把运行成本送回旧公司。组织树是管理结构图，拿它当结算凭证，仪式感很足，钱却没有跟着仪式走。

管理位置换了，付款连接没换

迁移也并非所有权限原样复制。来自原组织的继承权限会失去，新组织的政策开始适用。直接绑定在项目上的权限与从上层继承的权限，走的是两条路。对业务系统而言，同样的资源还在那里，能否沿用原来的访问和依赖关系，则要看新环境的实际政策。

付款是第三条路。迁移角色指南分别列出移动项目和调整账单所需的权限。它为后者列举目标账单账户的 Billing Account User、项目上的 Project Billing Manager 等角色；专门的账单指南还展开了查看、解除和建立关联所需权限。搬动项目的人，未必能替接收方接下账单。

这一区分有很实在的运营后果。按照更改项目账单设置的说明，项目启用结算，要求所关联账户处于有效且信誉良好的状态。账户关闭或暂停后，项目无法使用已启用的服务，即便其中一些符合免费使用条件。新组织已经管理项目，运行所需的付款条件仍可能掌握在旧账单账户一侧。

付款关系给旧账户留下的是供资依赖。谁拥有项目访问权限，仍由 IAM 规则决定。把“还在付钱”直接写成“还控制着项目”，会错过问题真正的所在：管理权与维持运行所需的条件，能够落在不同地方。

真正拖住交接的，可能是一封回复邮件

软件采购又增加了一套时钟。项目账单指南要求，迁移项目结算前，先转移项目关联的 Marketplace 购买。Google 的Marketplace 账单说明要求目标账户已经购买项目所需资源；控制台会对缺少相应购买的情况发出警告。一个项目一次只能关联一个账单账户，很难靠同时挂两张付款卡糊弄过去。

对直接从 Cloud Marketplace 购买的活跃订单，订单转移规则写得更有戏剧性。拥有 Billing Account Administrator 角色的客户先联系独立软件供应商。供应商同意后，向 Google 提出请求；Google 处理并发出审批邮件，相关各方回复同意，之后才完成转移并通知。

Google 给出的时间是可能一周或更久。这里没有一个保证七天完成的倒计时。项目管理员的按钮、供应商的同意和各方邮件回复，谁也不能替另一个完成工作。

还有一条足以让采购部门皱眉的限制：订单转移期间，如果目标账单账户从同一供应商购买产品，转移会变得不可行。限制针对同一供应商，范围比“别重复买同一个产品”更大。

急着让新公司拥有自己的软件，恰好可能挡住旧订单搬过去。问题出在动作次序。新购看起来是独立采购，订单转移看起来是后台手续，两支队伍如果各自追求“今天办完”，就可能把原本可走的转移路径堵上。此处的交接负责人需要协调供应商、财务和采购，单给云管理员加权限解决不了。

旧账单的尾巴，也要分清新旧

更换项目账单账户后，变更前已经产生的费用仍归旧账户，包括尚未报送的费用。不同服务的用量报送可能延迟最多两天。这是旧用量晚到，并非变更后的新用量额外送给旧账户两天。

这种差别决定了财务对账会不会把正常尾款当成迁移失败。账单账户还可能承担未归到具体项目的费用，例如 Support。项目列表已经清空，也不等于账户级支出清零。

优惠同样有自己的边界。对正在更换账单账户的项目中的 Compute Engine 资源型承诺用量，其折扣转到目标账户适用后，旧账户下的项目就无法继续享用这些承诺带来的折扣；新账户的共享设置决定新的适用范围。搬走一项资源承诺，影响可能落到留下来的项目身上。

服务套餐也会变化：如果目标账单账户没有 Cloud Armor Enterprise Annual 订阅，原来参加该年度方案的项目会回到 Standard。这里变的是明确的套餐权益。交接时只验机器是否还在跑，就看不到这种商业条件的变化。

留在旧账户，有时恰恰是安排好的

Google 在 2023 年 5 月 2 日发布的企业剥离架构文章，用假设的 RemainCo 和 NewCo 讨论分拆。它提出，为履行既有承诺合同，可以继续由原账单账户为迁出的项目供资；促销额度和支持套餐也不会自动延伸到新公司或新账户。

这让“旧公司仍在付款”有了两种完全不同的经济含义。一种是谈好的过渡安排，旧账户继续履约，新公司按约承担成本；另一种是交接报告只看组织归属，把供资关系遗留在原处。后台显示可以相同，双方掌握的责任却相差很远。

判断一笔实际交接，需要项目现有 IAM、账单关联、购买记录和各方审批记录；公开规则没有给出某家客户的这些材料。

规则已经足够说明谁该坐进交接会议。负责项目的人搬管理位置，负责账单的人接运行费用，软件供应商参与转移购买权利。交接完成的标准，应由这几方共同确认。否则，新公司的门牌挂得很端正，电费通知仍准确地寄往旧地址。