You inherited a cloud estate. Now what?

What has to happen in the first thirty days?

Establish control of the accounts, not control of the architecture. That means knowing who holds the root or global administrator credentials for every account and subscription, that those credentials have hardware-backed multi-factor authentication, that the billing relationship is owned by someone in your organisation, and that logging is enabled and shipping somewhere you can read.

Then close the access questions that have a deadline attached. Which departing employees still have credentials, which contractors and vendors have standing access, and which long-lived access keys exist and what they can do. Acquisitions coincide with departures, and standing access held by someone who has just learnt their role is redundant is a risk that has a date on it rather than a probability.

Everything else in the first month is observation. Turn on the audit logs, export the billing data, enumerate the accounts, and record what is publicly reachable. Resist changing things you do not understand yet, because the people who could tell you why a resource exists are the ones most likely to leave, and their knowledge is the asset that depreciates fastest.

How do you find out what is actually there?

Start from the bill, because it is the only complete inventory that exists. Every running resource appears in the billing export whether or not anyone documented it, whether or not it is tagged, and whether or not the person who created it still works there. Grouping the detailed export by account, service and region produces a map of the estate in an afternoon, and it will contain things nobody mentioned during due diligence.

Then reconcile from three other directions. The account or subscription list, which shows the administrative structure and often reveals dormant environments. The public DNS records for every domain the acquired company owns, which shows what is actually serving traffic and frequently points at infrastructure the engineering team no longer thinks about. And the identity inventory, showing every human and machine identity with access, which is the list that matters most and is almost never current.

The gap between what these four sources show is the useful finding. Resources with cost but no owner, domains resolving to addresses in no known account, accounts with no recent activity but with live credentials, and identities with permissions in accounts nobody claims. Each of those is either a risk to close or an unpaid bill to stop, and both are quick wins that build the credibility to make the slower decisions later.

Should you consolidate onto one provider?

Sometimes, rarely urgently, and the decision should be made workload by workload rather than for the estate as a whole. The instinct to standardise is strong, and the business case usually rests on operating cost savings that are real but smaller than the migration cost, particularly when the acquired product has its own roadmap, its own customers and its own team who know how it runs.

What can you consolidate without migrating anything?

The commercial and governance layers, and this is where the early value is. Bringing the acquired accounts under your own billing relationship or enterprise agreement can improve the rate on both estates immediately, because discounts are tiered on aggregate committed volume. That is a finance exercise with no engineering risk, and it frequently returns more in the first year than a migration would.

Governance consolidates almost as easily. Ship the acquired estate's audit logs to your existing destination, bring its identities into your directory and retire the local accounts, extend your tagging convention and cost allocation model to it, and apply your baseline guardrails at the organisational level. None of that moves a workload, and together they turn an opaque estate into one you can report on and control.

Vendor contracts are the third and most overlooked. Two companies commonly hold separate agreements for the same monitoring, security, data and support products, at two smaller volumes with two renewal dates. Consolidating those is unglamorous and produces savings that do not depend on any technical work succeeding, which makes it the most reliable line in an integration business case.

Which security gaps appear most often?

The same handful, in nearly every inherited estate, and they are worth checking in the first fortnight regardless of what due diligence reported. Root or global administrator accounts without multi-factor authentication or with credentials in a shared password store. Long-lived access keys, often in code repositories or CI configuration, several belonging to people who have left. Storage exposed publicly, usually created for a legitimate reason years ago.

Then the structural gaps. No audit logging, or logging enabled but retained in the same account it records, where anyone who compromises the account can remove it. No separation between environments, so a development credential can reach production data. Databases reachable from the internet with authentication as their only control. And no break-glass process, so a single departed administrator can leave an account effectively unowned.

Fix these in an order driven by exposure rather than by tidiness: anything publicly reachable first, standing credentials for departed people second, logging and its protection third, environment separation after that. It is tempting to begin with a policy programme that brings the estate up to your standard. That takes months, and the specific exposures above are the ones that get exploited in the meantime.

When is leaving it alone the right answer?

When the acquired product is self-contained, the team came with it, and the integration thesis does not require the systems to merge. In that case the estate is a supplier-like arrangement: it needs governance, security baselines, cost visibility and an owner, but not relocation. Many acquisitions are of exactly this kind, and treating them as migration projects consumes the first year of a team that was bought for its product knowledge.

It is also right when the acquired estate carries a constraint that would follow it anyway. If its customers contractually require a particular provider, or its data must remain in a jurisdiction your primary provider does not serve, migration is not available regardless of preference, and the correct response is to make the second estate governable rather than to plan its removal.

Whatever the decision, write it down with a review date and the condition that would change it. Inherited estates that are neither integrated nor formally left alone become the estate nobody owns: too small to justify attention, too connected to shut down, and quietly accumulating unpatched systems and orphaned credentials until an incident makes it everyone's problem at once.