The Tenant Didn't Get the Memo: Cloud Contracts After a UK Acquisition
Photo: business acquisition paperwork cloud contract laptop UK office, via as1.ftcdn.net
The deal closes on a Friday. By Monday there's a new logo on the intranet, a revised org chart, and a Slack channel called integration-general that nobody can mute. Somewhere in the middle of all that, your cloud contract is sitting exactly where it was — same terms, same billing entity, same renewal date — quietly unaware that the company around it has changed hands.
That gap between corporate reality and contractual reality is where UK cloud teams get caught out. Acquisitions and mergers don't automatically reassign contracts, reset support tiers, or move data residency commitments. The tenant doesn't get the memo. Someone has to send it.
Start with the paperwork, not the dashboard
The instinct after a deal is to look at the cloud console: check spend, check regions, check who has admin. Useful, but secondary. The first question is contractual. Does the agreement allow assignment to the new owner, and does it require notice or consent?
Lots of cloud contracts include change-of-control language. Some require written notice within a set period. Others require affirmative consent before the contract can transfer to a new entity. A few are relaxed about affiliates but strict about competitors. The definitions matter: who counts as an affiliate, what counts as a change of control, and whether a share sale triggers the clause in the same way as an asset sale.
Don't assume silence means permission. If the contract says notify, notify. If it says consent, ask. The last thing you need six months into integration is a procurement team discovering that the agreement was never properly transferred and that a renewal is now a negotiation with less leverage than you'd like.
Who is actually the customer?
In cloud contracts, the customer isn't always the company you think. It might be an old holding company, a dormant subsidiary, a shared services entity, or a reseller arrangement set up years ago by someone who has since left. After completion, invoices can keep going to the wrong place. Purchase orders stop matching. Finance starts asking why a cloud bill is landing in a legal entity that no longer trades.
Get a clean list: contract counterparties, order forms, billing entities, VAT numbers, purchase order processes, and the named billing contacts in each provider portal. Then check the data processing agreements. If the contracting entity changes, the DPA may need updating too. For UK teams handling personal data, that's not paperwork for its own sake — it's part of keeping the processing record honest.
Data residency promises don't travel by default
A UK business often buys cloud services with a simple promise attached: data stays in a UK region, or at least in the EU. That promise may be contractual, architectural, or both. After an acquisition, it can be quietly undermined by things that aren't about the storage region at all.
Who supports the workload? Where are the support staff? Which subprocessors are in the chain? If the new parent company has a global security operations centre or a follow-the-sun support model, does that change who can access the data? Those questions belong in the first month, not the first audit.
The new owner may also want to consolidate cloud estates. That's a reasonable ambition, but it can conflict with customer commitments, regulatory expectations, or the terms you sold internally. Check the residency language in the contract, the actual configuration in the cloud console, and the support access model. They should tell the same story.
Support entitlements and the named-contact shuffle
Enterprise support is often tied to a named account, a spending threshold, or a parent company's global agreement. An acquisition can change the entity size, the billing relationship, and the eligibility for the support tier you thought you had. Technical account managers move on. Escalation contacts go stale. Portal access is tied to email domains that may be retired.
In the first 30 days, test the support path with something small. Log a low-priority ticket. Check that the right people can see it. Confirm who the current named contacts are and whether the new entity needs to be added. Find out whether credits, service-level commitments, or support hours transfer automatically or need a variation.
The tenant is not an asset on the balance sheet
Cloud tenants have a way of becoming orphaned. The original admin leaves. A service account created during a migration still has global rights. Billing ownership sits with someone in the old parent company. API keys are in a password manager nobody can access.
Treat tenant ownership as an access review, not a finance task. Inventory global administrators, billing owners, domain verification records, break-glass accounts, and any integrations that authenticate via the old company's identity provider. Remove access that no longer belongs. Document who owns what in the new world. If the old owner needs temporary access for transition, give it a name, a purpose, and an end date.
Where the invoice surprises you
Post-deal cloud bills can jump for reasons that have nothing to do with usage. Committed spend may be tied to the old parent's agreement. Auto-renewals may have been set up by a team that no longer exists. Marketplace purchases might sit under a separate billing relationship. Resellers may not know the acquisition happened, so invoices keep flowing to the old entity while the new finance team queries them.
Build a simple transition budget line: proration, unused commitments, support fees, egress, duplicate tooling during integration, and any professional services needed to move billing entities or re-paper agreements. It won't catch everything, but it stops the first post-close invoice from being a complete shock.
Renegotiate selectively
An acquisition can be a useful moment to fix terms — but not every term. If consent is required for assignment, use that conversation to confirm data residency, support entitlements, termination rights, and renewal dates. Don't turn a straightforward transfer into a full re-procurement unless the deal genuinely warrants it. The priority is continuity: keep the service running, get the contract on the right entity, and remove the ambiguity that will otherwise resurface at the worst possible time.
The tenant didn't get the memo about the acquisition. Your job in the first 30 days is to make sure the contract, the billing, the access, and the data promises all catch up with reality.