A Geospatial Software Company Delivers Multi-Terabyte LiDAR Datasets Straight From S3 With Files.com Syncs

A geospatial software company builds AI software that turns mobile LiDAR scans into finished engineering deliverables. Its product reads the point clouds collected by scan vehicles and extracts the curbs, paint lines, utility poles, and signs that surveying teams used to trace by hand, then exports them to AutoCAD, Microstation, or an Esri feature service. The company serves state departments of transportation and national engineering firms, automating mapping work traditionally done by hand.

The raw material is enormous. A mobile mapping run produces terabytes of LiDAR and imagery, and the product ingests data from scanner makers, so files arrive in whatever form a counterparty's hardware produces. All of the company's processing ran on its own AWS platform. So the company's entire business depended on moving very large files between its own S3 storage and outside organizations it did not control. The company's production storage and its client-facing exchange were two systems joined by a manual step, and that step cost more with every client signed.

Terabytes in S3, Delivered by Hand

The production side worked. Raw datasets sat zipped in S3, where the company's pipeline processed them. The exchange side was manual. When a dataset had to go out to a client, someone at the company downloaded the zip from the bucket and re-uploaded it through FileZilla to the endpoint the client could reach.

That was a manual download and re-upload of terabyte-class files between two systems, on every delivery. Each transfer tied up someone's time and bandwidth, and a delivery could not start until someone was free to move it.

An AWS Org That Could Not Move Its Storage

The obvious fixes did not fit. The company could not relocate production data onto a transfer platform's storage: the processing pipeline was built on S3, and the company described itself flatly as an AWS org. It could not push the problem onto its counterparties either. Surveying firms and public agencies send and receive data as-is, in their own formats, and the company wanted a new client relationship to start without asking the counterparty to adopt new tooling.

Meanwhile, the exchange already carried multi-terabyte volumes across dozens of outside firms: national engineering companies, scanner OEMs, and state transportation agencies, each with its own scoped folder and login. What the company needed was an exchange layer that gave every counterparty a simple folder reachable in a browser or over SFTP, and that reached into S3 natively on the other side. Native S3 integration was the reason the company chose Files.com in the first place.

A Three-Click Connection to Production Storage

The company connected its S3 buckets to Files.com using Remote Servers, a credential handoff that takes about three clicks. The bucket contents appeared as folders inside the Files.com site, while the source files remained in S3. Files.com could work against the storage the company already ran rather than requiring a production data migration.

On top of that connection, a Files.com sync now copies ready datasets from S3 into the scoped folder of the receiving client. The first delivery sync was built for a national engineering firm, whose Files.com user now downloads in a browser or over SFTP. Nothing changes on the counterparty's side: same folder, same login, no visibility into the storage behind it. What changed is who does the carrying.

What a Delivery Takes Now

With the S3 connection in production, the company replaced a manual download-and-reupload step with a sync between two systems. Production datasets now reach the client's folder with nobody downloading and re-uploading them, removing FileZilla and the manual shuttle from the path.

Because the bucket is already connected, standing up the next delivery means defining another sync—not creating a new manual routine that grows with the client list. The pattern that replaced the shuttle applies to every delivery that follows.

The Storage Stayed Put

The company is still an AWS org. The processing pipeline runs where it always ran, the raw zips land in the same buckets, and nothing about the production architecture bent to accommodate a transfer product. What changed is the seam: a delivery used to begin with someone pulling terabytes out of S3 by hand, and now it begins with the file already moving toward the client's folder on its own.

That is the takeaway for any company whose product runs on S3 and whose deliverables have to leave it. The company never faced a choice between where its data lives and how it moves. Files.com connected to the storage instead of replacing it, and the manual work between the two disappeared.