One Files.com Governance Model Lets a Marketing Consultancy Add Business Units Without Merging Them

A B2B marketing consultancy was built out of other companies on purpose. It launched when several firms were merged into a single organization, with staff across North America and the UK.

One of those firms runs a business unlike the others: direct-mail data processing and mail tracking inside the USPS regime, exchanging data files around the clock through several hundred named client and vendor logins.

Acquisition is not just how the consultancy started; it is how it grows. More agencies have been bought since the launch. That strategy has a consequence for IT that most companies never face: the file transfer estate is never finished. Every company the consultancy acquires arrives with its own servers, its own users, and its own clients pinned to its own endpoints.

Files.com’s parent-and-child structure gave the company a reusable model instead. Today a corporate transaction at the consultancy no longer implies a file transfer project.

Every Merged Company Arrived With Its Own File Transfer Estate

The merger more than tripled the legacy consultancy’s headcount almost overnight, and each constituent brought its own way of moving files. Legacy FTP infrastructure was spread across several groups, each with its own approach. The consulting side ran client-facing SFTP natively on an Azure storage account. The direct-mail unit ran its exchange, several hundred logins strong, on its own custom domain with dedicated IP addresses that clients’ automated systems were pinned to.

There was even a stranger wrinkle. The direct-mail unit had already run that exchange on Files.com for years, after retiring its own SFTP server. When the consultancy selected Files.com as its centralized transfer platform with directory-driven access, the group found itself with two Files.com sites that were complete strangers: separate tenants, separate administrators, no shared governance.

Left alone, the fragmentation would compound with every deal. Each acquired entity meant another one-off integration project and another user base to administer by hand, with no single place to grant or revoke a person’s file access across the group.

What the fix had to deliver was specific. A single identity source and a single point of governance across the group. Each business unit keeping its own client-facing domain, its own protocols, and its own security policy. And a known landing pattern for the next entity.

Why One Consolidated Site Was the Wrong Answer

The obvious consolidation, moving everything into a single environment, failed those requirements two ways.

The units genuinely needed different rules. The direct-mail unit’s clients held it to stricter transfer protocols than the consulting side’s clients required. One shared environment would have meant one shared policy: either the strictest rules applied to everyone, or the direct-mail clients got less than they demanded.

The client connections could not move. Hundreds of client and vendor systems pointed at the direct-mail unit’s domain and dedicated IPs, many of them automated senders that nobody at the consultancy controlled. An endpoint change on a consolidation weekend would have required coordinated reconfiguration across hundreds of outside organizations, and every one missed would have become a broken feed.

A Governance Shell Over Fully Separate Child Sites

Files.com’s parent and child site topology gave the consultancy a structure that met all three requirements at once. The company created a new, blank parent site to act purely as an administrative shell, holding no files and no client traffic, run by a small group of super-administrators. The consulting and direct-mail sites became separate child sites beneath it.

A Files.com child site is a complete site: its own custom domain, its own dedicated IP addresses, its own sign-in configuration, its own security policy, all set independently of its siblings. That is what made the restructuring invisible from the outside. The direct-mail unit kept the domain and IPs its clients were pinned to, and several hundred client and vendor connections carried on exactly as before. Nothing was reconfigured or re-pointed.

Identity runs through Microsoft Entra ID. Staff sign in with SSO, and Files.com SCIM provisioning creates accounts from the directory, applies group memberships mapped to client folders, and cuts access the moment someone is removed from provisioning. Nobody administers file users by hand, per system, per entity.

A Repeatable Model for M&A

With the structure in place, the consultancy replaced per-entity file transfer administration with one governed model that matches how the company actually grows.

• Several hundred direct-mail client and vendor connections rode through the restructuring unchanged: same domain, same dedicated IPs, nothing for any client to touch.
• A small group of super-administrators governs both business units from the parent shell, while each unit keeps its own domain, its own protocols, and its own security posture. The direct-mail unit’s stricter client requirements never had to be blended into a shared environment.
• Access across the group is directory-driven. A new employee provisioned in Entra ID gets the right folder access automatically, and a departure revokes it everywhere at once.
• File transfer for the whole group now runs under one structure spanning the consultancy and its subsidiaries.

Because each child site is complete in itself, that separation holds as the group changes shape.

File Transfer That Changes Shape With the Company

Before the shell existed, absorbing a company meant absorbing its transfer estate; now it means provisioning its people and, where the business warrants it, standing up one more child site. The consultancy never standardized by forcing its companies into one environment. It standardized on Files.com’s structure instead: one parent for governance, and a fully separate site wherever a business genuinely needs to be its own.