Summary

  • Moving a Google Cloud project to a new organization leaves its original billing account attached, while inherited access and organization policies change.
  • Transferring active orders bought directly from Cloud Marketplace requires customer and software-provider approval and can take a week or more.
  • Buying a product from the same provider in the destination billing account during the transfer makes it infeasible. Procurement timing belongs in the handover plan.

A business can leave home in Google Cloud and keep charging its old parent's account. Move a project into a new organization and the billing association stays where it was. The organization chart celebrates independence; the previous payer continues funding the services.

This is the documented arrangement. Google's project-migration guide says the move changes the metadata identifying the project's parent. Its ID, number, data and resources remain, as do IAM roles granted directly on the project. Its original billing account remains attached. Cloud Billing accounts can fund projects across organizations.

For a business being sold or split off, that creates a gap between a successful administrative handover and an accepted financial one. The project administrator can finish moving the project before the recipient has taken over its costs. Software bought for the project can introduce another party whose agreement is still required. A screenshot showing the project under its new organization captures only part of the deal.

The purchase that stops the handover

The most arresting constraint sits in the rules for transferring active Marketplace orders. During a transfer, buying a product from the same provider in the destination billing account makes the transfer infeasible. The restriction concerns the provider, not merely a duplicate purchase of the particular product being moved.

An enthusiastic procurement team can therefore frustrate the very independence it is trying to establish. One team is arranging new purchases for the receiving company; another is transferring the existing order to it. Both can be making progress against their own task lists while the first changes the conditions needed by the second.

For products purchased directly from Cloud Marketplace, the transfer starts with a customer holding the Billing Account Administrator role contacting the independent software vendor. If the vendor agrees, it asks Google to make the transfer. Google processes the request and sends approval emails. All involved parties must reply with approval before the transfer is completed and confirmation sent.

Google says the process can take a week or more. A week is no guaranteed maximum, and feasibility still matters. The project administrator cannot substitute a wider set of permissions for the vendor's consent. Nor can an engineering deadline manufacture the outstanding replies.

The Marketplace billing guide requires the destination account to have purchased the resources the project needs and describes console warnings for missing purchases. The project billing guide instructs customers to transfer associated Marketplace purchases before migrating the project's billing. A project can be linked to only one billing account at a time. The commercial preparation has to precede the final switch.

A funding link survives the administrative move

The division of authority starts even before software orders enter the picture. Google's migration-role guide separates the permissions needed to move a project from those needed to change its billing account. For the latter, it identifies roles including Billing Account User on the destination account and Project Billing Manager on the project. The dedicated billing documentation also spells out permissions to view, unlink and link. Authority to relocate a project does not automatically confer authority to charge its new host's account.

Access within the project changes on a different basis. IAM permissions inherited from the old organization are lost, and the destination organization's policies apply. Directly assigned project roles remain. Keeping the resources in place leaves a separate question about the access paths and dependencies applications need under the new policies.

The billing relationship is operational too. According to the project billing documentation, enabling billing requires the linked account to be active and in good standing. If it is closed or suspended, enabled services cannot be used, including services eligible for free use.

The original payer can thus remain part of the project's operating conditions after its administrative home changes. Paying the bill does not by itself grant that payer IAM control. The significant split is between two distinct functions: administering the project and maintaining its funding. A handover that checks only one can leave the other on the wrong side of an assumed separation.

Some benefits leave with the departing business

Changing the billing link later does not create an immaculate accounting cutoff. Charges incurred before the change still go to the previous account, including charges not yet reported. Depending on the service, reporting can take up to two days. That is a delay in reporting old usage, rather than two further days of new usage charged to the former payer.

Some costs also belong to the billing account without being assigned to a particular project, including Support. An inventory of moved projects cannot by itself demonstrate that the old account has stopped incurring costs.

Discounts create another consequence for the business that stays behind. Resource-based Compute Engine commitments in the project whose billing changes apply in the destination account; projects in the former account stop benefiting from those commitments. Sharing settings in the destination determine which projects there can benefit. An operation that has moved nothing can lose an advantage when another operation takes its commitment elsewhere.

Service plans have their own account boundaries. A project enrolled in Cloud Armor Enterprise Annual reverts to Standard if its destination billing account lacks the Annual subscription. The resources may retain their identity while the commercial terms surrounding them change.

Those are specific consequences to price into a separation. Treating every project move as an isolated technical task overlooks effects on budgets and services outside the departing project. The company that keeps the rest of the estate has a reason to inspect the handover just as closely as the company receiving it.

Keeping the old payer can be the point

Google considered this possibility in its May 2, 2023 discussion of resource hierarchies for divested organizations. Using hypothetical businesses called RemainCo and NewCo, it describes retaining funding through the original billing account to meet an existing commitment contract. Promotional credits and support packages also do not automatically extend to the new company or billing account.

A continuing funding link can therefore be a deliberate bridge. Its economic meaning depends on whether the parties have agreed who bears the cost and what ends the arrangement. An agreed transition and an overlooked dependency can look identical in the console. Their owners' ability to explain and discharge the obligations is quite different.

Assessing an individual handover would require its actual IAM assignments, billing links, purchases and approval records; the public rules do not supply a customer's private file.

The rules do identify the people who must accept the result. The administrator hands over the project's position and access arrangements. The payer accepts the spending. The software vendor approves the transfer that requires its consent. Until those decisions fit together, the new organization has acquired a project with some old relationships still attached. Changing the name over the door is easy to photograph. Deciding who funds the life behind it is the rest of the job.