A Travel Platform Replaced an Acquired Company's Windows File Share With One Hardened Files.com Landing Zone for Future Acquisitions

A corporate travel and spend management platform operates across Europe and the US. Its growth has included a series of acquisitions.

Every one of those deals delivers more than customers and revenue. It delivers a company, with its own IT estate, including whatever that company had been using to move files. Someone at the group has to decide whether each piece of that estate gets absorbed or carried indefinitely.

The company's answer was to turn the Files.com tenant inherited with one acquired company into a hardened landing zone for the next. An acquired US business unit's Windows file share became the proof of that broader acquisition strategy.

Every Acquisition Arrives With Its Own File Infrastructure

When the group acquired that US business unit, its file transfer ran on a legacy Windows file share. To the group's security team, that share was a transfer surface it had not built and did not govern. It sat outside the controls the group ran on its own platform, and the team wanted it retired outright.

The harder part was structural. Folding an acquired US business unit into shared infrastructure meant keeping its data and its users cleanly separated from the rest of the group. And a company absorbing multiple acquisitions was not going to stand up a separate transfer platform for each one.

The Tenant Was Hardened Before the Acquired Unit Needed It

The group already ran a Files.com tenant, and it had arrived the same way the US unit did: inside an acquisition. It entered the group with an earlier acquired company, and the group's security operations manager inherited it. The security team took ownership of the configuration and hardened it: two-factor authentication enforced for every user, unused protocols locked down, permissions scoped by group and by folder. That work is what turned an inherited tool into something the team was willing to recommend across the group.

So when an acquired unit needed off a legacy file server, the requirements were already met inside the estate: transfer infrastructure the security team governed, with entities kept apart by permissions rather than by separate platforms. The acquired unit's file transfer moved onto the group's Files.com tenant.

Group Permissions Carved Out the Acquired Unit's Own Space

The acquired unit's own team started the move. They came to the security operations manager wanting to migrate off the Windows share, and the answer was to retire it at once and land the work in the tenant instead.

Using Files.com group permissions and folder-level access control, the acquired unit got its own space inside the shared tenant. Its users belonged to their own groups, and those groups reached the unit's folders and nothing belonging to the other entities. The controls the security team had already built applied to the unit's users from the day they landed, including enforced two-factor authentication and the locked-down protocol surface. Nothing new was stood up: no server, no second platform, no separate administration. The Windows share was decommissioned.

The Share Came Off, and the Pattern Held

• The Windows share was retired straight away, taking a legacy transfer surface the group did not govern off its books.
• The acquired unit landed on controls that already existed, with access scoped to its own folders, and never had to run a hardening project of its own.
• The group replaced a standalone server with a permission-scoped space on infrastructure its security team already governed.

The ongoing administrative overhead is close to zero. The security team barely touches the platform day to day, and it keeps running anyway. That low-touch model matters across repeated acquisitions because each new entity can be absorbed without adding another transfer platform to administer.

Files.com, which itself entered the group inside an acquisition, became the place later acquisitions land. Retiring an acquired company's legacy file transfer stopped being a project at the group. It became the default.