Migrating Cloud Accounts After an Acquisition: A Practical Playbook

The deal closed. Now what?

The ink is dry, the press release is out, and someone in infrastructure just realized that the acquired company runs its production workloads on a completely separate set of cloud accounts. The AWS accounts are in a different Organization. The Azure subscriptions are under a different EA enrollment. The GCP projects bill to a different billing account. None of them talk to your existing infrastructure.

Cloud account migration after an acquisition is one of those problems that looks straightforward in a planning deck and turns into a six-month project in practice. The accounts need to be consolidated, but doing it wrong can disrupt production, invalidate discount commitments, and create billing chaos. Here's what the realistic playbook looks like.

AWS: Organizations payer consolidation

AWS accounts belong to an Organization, and each Organization has a single management (payer) account. After an acquisition, you typically want to move the acquired company's accounts into your Organization. This is conceptually simple — invite the account, accept the invitation — but the implications are significant.

RI sharing changes immediately.When an account joins your Organization, its Reserved Instances become shared across all linked accounts (unless you've disabled RI sharing). This means the acquired company's RIs might start covering your workloads instead of theirs — or vice versa. If you're not tracking coverage carefully, utilization metrics will shift in ways that look like problems but are actually just redistribution.

Savings Plans transfer with the account. Unlike RIs, which can be scoped to a specific account, Compute Savings Plans automatically apply across the Organization. Moving an account with active Savings Plans changes the coverage landscape for every account in the Organization.

Service Control Policies apply at the moment of join.Your Organization's SCPs will immediately govern the acquired accounts. If your policies are more restrictive than theirs — which is common — services may break. Audit the acquired accounts' IAM patterns against your SCPs before initiating the move.

The typical timeline for AWS account consolidation is 30–60 days for the billing migration, with another 30–60 days for IAM and SCP alignment.

Azure: EA enrollment merges

Azure is often the most complex to consolidate because of how Enterprise Agreements are structured. The acquired company likely has its own EA with its own enrollment number, its own monetary commitments, and its own set of subscriptions.

Merging two EAs requires working with Microsoft. The process involves creating a new enrollment (or expanding the existing one), transferring subscriptions, and reconciling monetary commitments. This is not a self-service operation — it requires coordination with your Microsoft account team and typically takes 60–90 days.

Reservation portability is limited. Azure reservations are scoped to an enrollment. When subscriptions move to a new enrollment, existing reservations may not follow automatically. You may need to cancel and re-purchase, which can create coverage gaps and potentially lose favorable pricing terms.

Azure Savings Plans behave differently.They're scoped at the billing account level and can apply across subscriptions within the same billing scope. During an enrollment merge, verify that Savings Plans will continue to apply to the workloads they were purchased for.

GCP: billing account transfers

GCP's model is simpler in some ways. Projects can be moved between billing accounts without disrupting the resources running inside them. The billing relationship changes, but the infrastructure stays in place.

The catch is Committed Use Discounts. Resource-based CUDs are tied to a project and region — they stay with the project when it moves. Spend-based CUDs are tied to the billing account — they don't transfer when projects move to a new billing account. If the acquired company has active spend-based CUDs, moving their projects to your billing account means those CUDs continue to decrement against the old billing account (which may no longer have significant spend), while the projects on your billing account lose their discount coverage.

The typical GCP migration timeline is 15–30 days for the billing transfer itself, but CUD reconciliation can extend the effective timeline to 60–90 days.

The realistic timeline: 90 to 180 days

Despite what integration playbooks suggest, full cloud account consolidation across all three providers realistically takes 90–180 days. The breakdown:

• Days 1–30: Inventory all accounts, commitments, and billing structures. Map the target state. Identify conflicts between SCPs, IAM policies, and security baselines.
• Days 30–60: Begin AWS account moves and GCP billing transfers. Start the Azure EA conversation with Microsoft.
• Days 60–120: Complete AWS consolidation. Complete GCP transfers. Azure enrollment merge in progress.
• Days 120–180: Azure consolidation complete. Reconcile all commitment instruments. Optimize discount coverage across the now-unified estate.

Common mistakes to avoid

Moving accounts before auditing commitments.Know what commitments exist, when they expire, and how they'll behave in the new billing structure before you move anything. Refer to our first 90 days guide for the full assessment framework.

Assuming discount coverage will be maintained.It won't. Every account move disrupts the existing coverage model. Plan for a temporary increase in effective costs during the migration window, and have a re-optimization plan ready for when consolidation is complete.

Treating it as purely an infrastructure project. Cloud account migration is equally a finance project. Billing structures, cost allocation, chargeback models, and discount strategies all change. Finance, procurement, and FinOps need to be at the table from day one, not informed after the fact.

For organizations going through acquisitions regularly — particularly PE portfolio companies — having a repeatable cloud integration playbook and an enterprise cloud management partner turns a 180-day scramble into a structured process with predictable outcomes and clear milestones.