How an Agency Absorbed 40 Acquired Accounts Without a Migration

The deal closed on a Friday. By the following Tuesday, this agency owned a competitor's entire book of business — and with it, forty client ad accounts it had never touched, scattered across separate logins and Business Managers. The plan everyone assumed they would follow was a migration project: collect every credential, log into every account, re-enter everything by hand over a few painful weeks. What actually happened is the subject of this case study on how to run an agency acquisition consolidate ad accounts handover — because the agency dropped in one acquired System-User token, let auto-discovery surface every account, and was operating both books from a single workspace before the migration was ever scheduled.

This is a composite drawn from how real agencies handle post-acquisition consolidation. The names and exact numbers are illustrative; the handover problem, and the shape of the fix, are not.

The deal closes: now you own a competitor's client portfolio

Acquiring a smaller agency is a normal way to grow a book of business: you buy the client relationships, the retainers, and the people who service them. On paper, the agency had just added forty accounts overnight. In practice, it had inherited a tangle — the acquired shop had run its accounts the way most agencies do before they outgrow it, with a spread of logins, a couple of Business Managers, and access knowledge living in a few people's heads.

The agency's own house was in order. It already operated its existing clients through a single layer with named seats and scoped roles, the opposite of the shared-login chaos described in why shared logins are killing your ad agency. The problem was absorbing forty accounts run by someone else's conventions, fast enough that the inherited clients never felt the seam. An acquisition transfers the contracts instantly and the operating reality slowly, and the gap between "we own it" and "we can operate it" is where post-acquisition handovers stall.

The hidden cost of M&A: dozens of accounts behind separate logins

Walk the inherited portfolio and the cost of the old structure becomes concrete. Forty accounts did not mean forty tidy entries. It meant two Business Managers set up at different times, a scatter of accounts attached to each, several the previous owners reached through client-granted logins, and a handful where the only path in was a shared password three former employees knew.

None of that is unusual; it is what an agency's access layer looks like when it grows one client at a time. But it turns every acquisition into an archaeology project: before you can run an account you have to find it, confirm who can reach it, and establish your own way in — forty times, across several platforms.

The usual plan: a credential-by-credential migration measured in weeks

The agency's operations lead scoped the obvious approach first. List every account; for each one, identify the access path, collect the credential, log in, confirm a durable way in that did not depend on a former employee, and re-establish it under the agency's own structure. Then the next account, and the next, across two Business Managers and several platforms.

Estimated honestly, that is weeks of fragile work. Every shared password is a single point of failure — if a departing employee changes it or stops answering, an account goes dark. Every client-granted login has to be re-confirmed so the relationship survives the ownership change. And the whole time the migration runs, the inherited clients are in limbo: technically the agency's responsibility, practically still half-managed through the old shop's logins. The team had run smaller versions of this before — the first-week scramble covered in their own playbook for onboarding a new client account in week one — and at forty accounts that scramble does not scale.

The shortcut: dropping in the acquired System-User token

There was a shortcut, and it changed the shape of the whole project. The acquired agency, like most agencies operating at scale, had issued a System-User token at the Business Manager level for its platform integrations. A System-User token is not a personal login tied to one employee; it is a durable, business-level credential that already carries access to every ad account its Business Manager manages. The agency did not need forty credentials — it needed the token, acquired with the business.

So instead of starting a migration, the operations lead did one thing: dropped the acquired agency's System-User token into the operating layer, the same connect-once mechanism the agency already used to onboard a client account without ever sharing a Meta login. One token, one paste, for an entire Business Manager's worth of accounts. The migration plan would have touched every account individually; the token touched the layer that already held them all.

What auto-discovery surfaced: every account and BM, no manual inventory

What happened next is why the migration project never ran. The operating layer read the token, resolved the business_id behind it, and enumerated the accounts automatically — every ad account under that Business Manager, surfaced without anyone typing a list. The second Business Manager came in the same way with its own token, and between the two the bulk of the forty accounts was visible in an afternoon.

There was no manual inventory because the token already knew the inventory. Auto-discovery via business_id meant the source of truth for "which accounts exist" was the Business Manager itself, not a spreadsheet reconstructed from former employees' memories. The handful of accounts held through client-granted access rather than the acquired BM still needed individual re-confirmation, but they were a short tail, not the whole project.

Mapping the inherited team into internal RBAC roles

Surfacing the accounts was half the job; the other half was deciding who could touch them. The acquired agency had retained some buyers as part of the deal and let others go, and the agency was not about to replicate the old shop's access sprawl. With the accounts now inside the operating layer, governing who worked them was an internal decision, not a property of the platform logins.

The operations lead assigned scoped roles. Retained buyers got named seats matched to the accounts they would keep servicing, so the client relationships stayed warm through people the clients already knew; the agency's own leads got oversight across both books; departing staff got nothing. Nothing needed to be revoked on the native platforms, because none of the inherited buyers were ever operating through the underlying logins. They worked through internal roles over a single connected token, the model the agency uses to keep separate logins from becoming the operating layer. Access governance happened once, instead of forty times across native permission screens.

Operating both books from one workspace within the first week

By the end of the first week the agency was running its original clients and the forty inherited accounts from the same workspace. The scaling meeting, the launch queue, the reporting — all of it covered both books at once, in one view instead of toggling between the agency's own structure and the acquired shop's two Business Managers. The inherited clients got the agency's standard reporting cadence immediately rather than after a transition quarter.

The clients felt nothing. No password resets, no "we're migrating your account" emails, no gap in management — the agency that bought their old shop simply kept running their ads. The weeks of half-managed limbo a migration would have created never existed.

Lesson: when the token does the discovery, an acquisition is a connect

Asked afterward what they would tell another agency facing an acquisition, the operations lead's answer was specific: before you scope a migration, check whether the access you are buying includes a Business Manager System-User token. If it does, you are not migrating forty accounts — you are connecting two Business Managers and re-confirming a short tail of client-granted ones, and your real work is the governance layer on top.

That reframe is the whole lesson. A migration assumes the work scales with the number of accounts; a connect assumes it scales with the number of access paths — and a System-User token collapses an entire Business Manager into one path. The agency consolidated forty accounts in an afternoon because auto-discovery via business_id had already done the per-account work. The same pattern holds across the six ad platforms the operating layer supports, so an acquired book spanning Meta, Google, TikTok, Taboola, Snapchat and Outbrain comes in channel by channel rather than account by account.

Wevion's plans start at a permanent free tier (€0), then Starter at €99/mo, Pro at €499/mo, and Plus at €1,499/mo (€1,199 annual, billed yearly at -20%), with Enterprise as a custom plan, and every paid tier includes a 14-day trial that coexists with the free plan. Connecting a System-User token and watching the accounts auto-discover sits inside that. The rest of the playbook lives in the agency tools cluster.

The takeaway generalizes to any agency that grows by acquisition: the size of the handover is not the number of accounts you bought, it is the number of distinct ways you have to reach them. Inherit the token that carries the whole Business Manager, let discovery do the inventory, govern the inherited team through internal roles — and the migration you were dreading turns out to have been a connect step.