A Global Testing and Certification Company Moved Its Multi-Terabyte Working CAD Repository from Dropbox to Files.com

A global testing, inspection, and certification company operates in dozens of countries. One of its business lines runs a certification program for automotive replacement parts.

Operating that program is, to a large degree, a file operation. Dozens of approved parts manufacturers submit test results, certification applications, invoices, and program forms. The company’s own labs return results. Its internal applications process what arrives. And behind all of it sits the program’s engineering data: the CAD design files its designers work from every day.

A Governed Exchange on One Side, Terabytes of CAD Files on the Other

The exchange side of the program ran on Files.com. Manufacturers and labs connected over SFTP and the web portal, under the program’s own branded domain. Access was managed through groups and folder-level permissions, with subfolders locked down and inactive accounts disabled automatically. The company’s in-house systems drove the site directly through the Files.com REST API, making tens of thousands of calls on a typical day.

The engineering side did not. The designers’ working corpus, several terabytes of CAD files, lived in Dropbox. Every control the company had built for the exchange stopped at its edge. The design data answered to Dropbox’s account model instead: separate users, separate permissions, and a second administration surface to keep aligned with the first. The largest body of files in the program was managed apart from everything else in it.

The split persisted because the corpus was genuinely hard to move. The entire Files.com site was a fraction of the size of the Dropbox corpus. And the corpus was not an archive. Designers worked in it daily, and it grew every month, so each month the separately governed estate got larger and the gap between the two got wider. Any fix had to move terabytes in bulk, land the result as a live working repository rather than a backup, and do it without disturbing the exchange running on the same site.

The company chose to consolidate: the CAD corpus would move onto Files.com, into the site that already governed the rest of the program.

A Parallel Sync Landed the Corpus in a Single Folder

Working with Files.com’s onboarding engineers, the company ran the transfer as parallel sync jobs, moving several terabytes of CAD files out of Dropbox and into a dedicated folder on the existing site. The site’s footprint grew by an order of magnitude.

The corpus inherited the site’s access model the moment it landed. Designer access now sits within the same groups and folder-level permissions the company already administers for the certification exchange.

One Site Carries the Exchange, the Integration Traffic, and the Design Corpus

With the migration complete, the company retired a parallel file estate. What had been two platforms with two access models is now one Files.com site:

• The program’s design data sits under the same controls as manufacturer submissions. Dropbox is out of the workflow.
• Growth lands governed by default. Each month’s new CAD work arrives into the same folder under the same rules, so there is no second platform drifting further from the first.
• Administration happens once. Access for a designer and access for a manufacturer are decisions made in one place, against one model.
• The exchange never changed. The program’s manufacturers, labs, and API integrations kept connecting exactly as before while the site behind them grew many times over.

The Program’s Files Now Answer to One Set of Controls

Before the migration, keeping two file estates aligned was standing work that advanced nothing.

The consolidation carries a plain lesson: a multi-terabyte working repository did not need its own file-sharing product. It needed a folder on the platform that already governed the rest of the program, and Files.com absorbed it, monthly growth and all.