The Acquisition Closed. The Repositories Are Yours Now.

The map has to be built after signing

Accountability transferred at signing. Whatever runs in the acquired company's production environment runs under your name, and the incident that starts on Tuesday gets reported as yours. Where that code lives is a question the data room leaves open.

Diligence answers the questions that could break the transaction. Who owns the intellectual property. Which open source licenses carry obligations that survive a change of control. Whether the financials hold and the engineering team stays. Those get answered by lawyers reading documents and by a technical reviewer sampling a representative slice of the code. Sampling is the right method for that question. It produces a judgment about quality, and a count is a separate output that somebody has to commission.

Where the estate goes uncounted, the reasons sit on both sides of the deal.

• Engineering leadership answers from memory, and memory is organized around the products that make money
• Source control tenants get stood up team by team, so a single list may never have existed on the seller's side either
• Contractor and agency organizations get provisioned outside the seller's identity system, which is how they stay off an asset register
• Repositories for sunset products keep building, because switching off a pipeline needs an owner for the decision
• The people who can recite the estate from memory hold that knowledge personally, and retention packages have end dates on them

The question that arrives in week one

Somebody asks whether the acquisition changed the company's exposure. The audit committee, a customer's third-party risk team reading the press release, a regulator with a notification clause. In week one the honest answer is that you are finding out, and that answer has a short shelf life.

The denominator is what is missing. Coverage is a fraction. You can repeat the finding counts the acquired company's scanners produced last quarter, and they mean nothing until you know what those scanners covered. A coverage percentage measured against an estate of unknown size reads as reassurance right up to the day somebody finds the fourth tenant.

The board question and the inventory are the same piece of work, which is the argument for starting the count in week one.

Coverage is a fraction, and you inherited the numerator.

Days one through ten: access is the whole constraint

The first ten days go on credentials, and provisioning them runs long, because the administrators who hold them became your employees last week.

Read access to every source control tenant is the deliverable, and the word every is doing the work. The first conversation names the tenants attached to the products the deal was about. The instances a team stood up during a project years ago and kept to itself are the ones you need. Ask what builds and deploys to production: a pipeline that runs has a service account, a runner and a bill, and all three leave records that route around the org chart.

Run the interviews while the people are still there. Retention packages have dates on them and institutional memory leaves on those dates. An engineer who can name four tenants in one conversation saves you a month of tooling.

• A named administrator for every source control instance, with their notice period recorded beside the name
• Read access provisioned to your team, dated, with a fallback if that administrator leaves before it lands
• Billing records for source control, CI, artifact registries and cloud accounts, since paid seats and running pipelines leave records whether or not anyone wrote the tenant down
• Identity provider group membership for the internal teams, plus purchase orders and OAuth application grants for the contractor and agency organizations provisioned outside that system
• A written tenant list from the seller's engineering leadership, signed and dated, so a discovery in month five costs a scope adjustment and nothing more

What the inventory records when the code arrived with the deal

The fields are the same in any estate: identity, ownership, activity, exposure, build path. Two of them behave differently when the code arrived through a transaction.

Ownership is the field that breaks first. In an estate your own engineers built it is stale or informal, and somebody knows the answer. Here the CODEOWNERS file names a team that no longer exists, the last committer may be on a package that ends in six months, and the person your org chart points at joined during the integration. Record who owns each repository today and the evidence behind that answer. The two diverge faster in year one than at any later point.

Exposure changes because your obligations changed. A repository that sat inside the acquired company's risk appetite now sits inside yours, and those are different documents. Code that shipped to the acquired company's customers now ships under your name, against notification clauses the seller never signed.

Beyond those two, an inherited estate needs fields a homegrown one can leave implicit.

• What is live in production right now, taken from deployment records, since a repository's own appearance of activity misleads here
• Which repositories hold code the acquired company did not write: contractor deliverables, forked open source, and anything delivered under an agreement that may not have survived the change of control
• Credentials committed to source control, tracked with a clock of their own, since every account that was the seller's problem is now yours
• External access that still works: contractor organizations, agency accounts, and the leaver whose offboarding belonged to a process that has stopped existing
• Where regulated data sits, since the classification you inherited was written against somebody else's obligations

Every field in an inherited inventory needs a second column recording how you know.

Days eleven through thirty: from a count to a position you can defend

The count is an input. Week five needs a statement that holds up: what you own, which part carries the exposure, what you are doing about it, and what you deferred and why.

Funding coverage across a whole inherited estate in the first quarter produces a plan that fails in public. Rank on exposure and on fan-in, which is what carries blast radius, then check the ranking against ownership, and use activity to sequence the work once the order is set. A repository that clears the exposure filter with no accountable name against it needs an owner before it needs a scanner, and assigning one inside a merging company is a negotiation between leaders who each have other commitments.

CWS has done this discovery at scale once, on an estate of roughly 6,300 repositories. That engagement was estate discovery, and that is the whole of the claim. The method carries because the starting condition matches: repositories nobody in the room wrote, tenants nobody had enumerated, ownership that had to be established from evidence. Expect what the counting found there. The tenant list is incomplete. Archived and never deleted repositories inflate the number badly. The shared library with a wide dependency footprint outranks the busy customer-facing application, and it stays invisible where the ranking runs on commit volume.

Thirty days is a judgment about how long a new owner can credibly go without a number, not a period any standard sets. The sequence below follows from that judgment, and five things come out of it.

• A tenant map naming every source control instance found, and the access that exists against each today
• The tiering, with thresholds written out and attributed to whoever set them, on a date
• A gap list covering repositories with no owner, no pipeline, no determinable exposure, and no access yet
• A phased scope stating what the first quarter covers and the criterion each deferral rests on
• A re-baseline trigger written as a percentage, so the tenant found in month five reopens the plan under a rule everyone agreed in advance

Thirty days is enough to know what you own. It is not enough to have fixed it, and the integration plan should say so.

What belongs in writing before the plan is signed off

The integration plan gets drafted whether or not the inventory exists, because integration programs run on a calendar the deal set. What you control is the assumptions it carries and whether anyone labeled them.

Write the assumption down and label it. Planning assumes approximately this many repositories across this many tenants, as stated by this role on this date. An assumption on the record is something you can point at in month six. The same figure unlabeled in a spreadsheet becomes a number you are asked to justify, by somebody who has just found a tenant you never saw.

Four things belong in writing before the plan circulates, and each is cheaper to agree now than to reconstruct in month six.

• The date the count is delivered, carried in the integration plan with the same standing as a systems cutover
• The name of the person who signs the tenant list as complete to the best of their knowledge
• The treatment of forks, mirrors, archived repositories and monorepos, since forty services in one repository count as one row or as forty, and the coverage denominator and the tiering rows both move with the answer
• What happens to repositories that reach day thirty with no owner, a decision about people that belongs to whoever runs the integration