NV5 Shut Down Its Peak-Sized On-Premise FTP Servers and Moved 30 Petabytes Through Files.com

NV5 Global is an infrastructure engineering and technical consulting firm with roughly 5,000 engineers, inspectors, and analysts. Its geospatial division, NV5 Geospatial, conducts aerial data acquisition and processing for government agencies and commercial clients, using aircraft-mounted lidar and imaging sensors.

At most companies, file transfer supports the product. At NV5 Geospatial, file transfer ships it. Every project ends the same way: raw sensor data comes in from the field for processing, and finished product goes back out to the agency that ordered it. Aerial lidar and imagery produce enormous data sets, and individual production users move multiple terabytes in a single day. The deliverable is the data, and the data has to move.

NV5 needed to stop owning infrastructure sized for its seasonal peak without disrupting the pipelines and counterparties already wired to it.

An FTP Estate Sized for Three Months a Year

For years, NV5 ran that exchange on FTP servers it owned and operated itself. Owning the servers meant owning the peak. Flight and project cycles concentrate the volume into a May-through-July window every year, so the IT team of a consulting firm had to run data-center-scale transfer infrastructure as a side duty: internet-facing servers it sized and patched year-round, built for a load that exists for one quarter of the calendar.

The workload had already reached tens of terabytes a month before the servers came down. A transfer operation that size is a commitment, not a sideline.

The servers survived as long as they did because the counterparties were wired to them. Production pipelines spoke SFTP. Clients and vendors connected with the desktop FTP tools they already had, FileZilla among them, and one client was permitted to run only FTP Voyager for file transfer, full stop. Any replacement had to keep every one of those connections working, while also giving partners with no client at all a way to retrieve a delivery folder that runs to hundreds of gigabytes.

A Parallel Run, Then the Server Came Down

The replacement had a clear specification. It had to serve SFTP, FTP, and FTPS as managed endpoints, so pipelines and counterparties changed nothing. It had to offer a browser path for partners who would never install a client. It had to accept drop-offs from outside vendors and consultants. And it had to flex with the season instead of being sized for it.

Files.com gave NV5 that layer without asking any counterparty to change. Vendor uploads into structured Files.com distribution folders dated back to at least 2017, so the two environments coexisted for years as NV5 moved the exchange across. NV5 deactivated the on-premise server in September 2020. The company has not hosted its own transfer infrastructure for this workload since.

SFTP for Production, Share Links for Delivery, an API for the Automation

Production traffic runs over Files.com's SFTP and FTPS endpoints. The heavy users connect the way they always did: staff and outside counterparties reach the site with the same desktop FTP clients they used against the old servers, and the client restricted to FTP Voyager connects over plain FTP, which Files.com serves alongside the encrypted protocols. The protocol surface asks nothing new of anyone.

Outbound delivery to partners without a client goes by Files.com Share Links. NV5 shares a finished delivery folder, often hundreds of gigabytes, as a link the partner opens in a browser and downloads directly. No account, nothing installed, and the delivery no longer depends on the recipient's tooling.

Inbound drop-off works the same way in reverse. Outside assessors, consultants, and vendors upload directly into structured distribution folders on the site, where NV5 retains the data.

Underneath the human traffic sits the machine traffic. NV5 drives Files.com through the REST API and CLI, and during the July 2022 peak the site handled more than 300,000 API requests in a single day. The same site also gives NV5 offices on separate Windows domains common ground: a folder and a permission are all two offices need to share project data.

Peak Season as Usage, Not a Capacity Project

With the cutover complete, NV5 replaced an exchange it hosted with an exchange it uses. The difference shows up every flight season.

• Roughly 30 petabytes of data has been used, moved, and archived across the relationship, on infrastructure NV5 never had to size or patch.
• Peak season arrives as load, not as a capacity project: at the 2025 peak, the site moved more than 10 TB outbound in a single day, and nobody at NV5 provisioned anything to make room for it.
• The concentration that strains self-hosted infrastructure is ordinary here. During that same peak, three SFTP users carried nearly 80% of daily transfer volume.
• Every counterparty kept its tools: pipelines still speak SFTP, clients still run the FTP software they are wired to, and partners with nothing installed collect deliveries in a browser.

The exchange also grew a second job nobody planned. Chris Meadors, NV5's Manager of IT Business Services, found that data sharing between offices on separate domains had become more significant than initially anticipated. The platform turned into internal infrastructure on its own, because the next office needing to move data across a domain boundary simply uses what is already there.

Thirty Petabytes Later

A petabyte-scale exchange with a violent seasonal peak does not have to dictate the infrastructure a company owns. NV5 kept the protocols, kept the counterparties, and kept the peak. What it gave up was the servers.