A Demand Generation Company Replaced Dropbox and a Google Drive Workload With Repeatable Files.com Cutovers

A B2B demand generation and data intelligence company sells to enterprise marketing and revenue teams, and the core exchange with them is a file: the customer sends its CRM data in, the company enriches it against its own first-party data set, and sends it back. Files full of other companies' customer records cross the company boundary constantly, and the company wanted one governed path for every one of them.

The company has also grown fast for a long time, and much of that growth came by acquisition. Every acquisition brought people, customers, and live workflows. It also brought whatever tool that team already used to move files.

Four Sharing Tools and No Single Front Door

By 2024, external file sharing at the company ran through Dropbox, Dropbox DocSend, OneDrive, and Google Drive, depending on which team you asked. The sprawl was not a choice anyone had made. It was an inheritance: acquired teams arrived with their tools attached, and their customer-facing work kept running in them.

IT wanted one governed path for customer data entering and leaving the company, in place of accounts chosen team by team. It wanted one tool to administer instead of several that overlapped. And it wanted a sanctioned way to exchange files larger than the 50 MB cap on the outbound mail path.

None of these tools was idle. Each one carried real customer-facing work, and pulling them all out in a single cutover would have meant coordinating every department and every external customer at once. And each new acquisition added another tool to the estate.

What the fix had to do was clear. One platform for files entering and leaving the company, running under the company's own name rather than a vendor's. Links and upload pages easy enough that sales and customer-facing teams would actually use them instead of reaching for the old tools. And because the files hold regulated personal data, control over where specific folders physically live. But consolidation also had to happen one tool and one workload at a time, with a repeatable way to move content and set a cutoff rather than a company-wide cutover.

The company selected Files.com as that single platform.

A Branded Domain and a Sync Engine Instead of a Migration Project

Files.com became two things at once for the company: the branded front door for files entering and leaving the company, and the engine that emptied the workloads it replaced.

The front door came first. The company stood up a Files.com custom domain under its own name. Every login page, share link, and upload page the company sends carries its own name; the platform underneath does not appear.

The emptying ran through Files.com Remote Server Sync, which connects to Dropbox and Google Drive directly and moves content between systems without anyone downloading and re-uploading it. In the spring of 2024, it pulled the legacy Dropbox content across, including a single multi-terabyte shared folder. The company set a hard cutoff for May 2024 and shut Dropbox down for that workload. In January 2025, the same engine moved a second legacy workload out of Google Drive, and the source data was deleted once the sync completed.

Day-to-day exchange now runs on Files.com. Customer data exchange uses a folder per customer, each with its own upload share links, so one customer never sees another's files. Password-protected, upload-only links collect inbound files, including large video files, from people who never need an account. Outbound, teams send branded share links instead of attachments, so the 50 MB mail cap no longer decides what can be exchanged. Folders holding regulated data are pinned to specific geographic regions, the UK among them, which makes residency a folder setting rather than a policy memo. And integration with the company directory automatically creates access when people join and removes it when they leave, so nobody keeps a path to customer data after departing.

A Repeatable Way to Retire Each Workload

With the branded domain in production, the company started shutting down inherited workloads one at a time. Instead of turning each retirement into a bespoke migration project, the company could connect the source as a remote server, sync the content across, set a cutoff, and shut down that workload. It used the pattern first for legacy Dropbox content and then for a second legacy workload in Google Drive.

Retiring a sharing workload became a repeatable move rather than a project: connect it, sync the content across, set a cutoff date, shut it down. The hard part of consolidation was never any single migration; it was that every migration used to be its own bespoke effort. With the sync engine and the cutoff pattern established, absorbing the next workload costs a fraction of what the first one did.

Those were the first completed retirements, not the whole four-tool estate. The company still targeted Dropbox DocSend for removal, with its specialized asset-delivery and engagement-tracking behavior to account for. Departmental sharing in OneDrive and Google Drive remained a later phase behind the initial teams and workloads.

An Acquisition No Longer Adds a Permanent Silo

Today, when a salesperson needs to move a file the mail server will not take, or a customer needs to send data in, the answer is a page under the company's own domain, not whichever account happens to be closest. For a business whose product is other companies' customer data, where that data crosses the company boundary is now one governed path under the company's own name, whichever team or acquisition the work came from.

Files.com changed what an inherited tool means at the company. Absorbing an inherited tool used to mean a migration project of its own. Now it means some content to sync and a cutoff date to communicate. The consolidation did not require a company-wide cutover. The work proceeded one tool and one workload at a time, each retired the same way, which is exactly why it could happen at all.