GPRS Replaces Autodesk ShareFile and Google Drive With Files.com—Without Moving Its Azure Blob Data
Ground Penetrating Radar Systems (GPRS) is the largest private utility locating company in the United States. Its field project managers locate buried utilities, scan concrete, and inspect pipelines in every major American market, with just under 1,000 employees across 60 cities.
What GPRS sells, in the end, is data. A field visit becomes a deliverable: a CAD site plan, a 3D Revit model, a point cloud of an entire facility. When GPRS acquired Existing Conditions, a reality capture firm, in 2024, that side of the business grew. A second team now produced point clouds, as-built drawings, and BIM models for architecture, engineering, and construction clients. A reality capture deliverable averages 10 to 20 gigabytes, sometimes more, and every one of them has to land inside a client's network. GPRS controls nothing about that network.
The acquisition also left the combined company with two client-delivery platforms. GPRS would use Files.com to replace Autodesk ShareFile and Google Drive with one browser-based layer over its existing Azure Blob storage—without moving the underlying data or changing the production pipeline.
Blocked at the Client's Firewall
GPRS delivered those files through a high-speed transfer tool that required the recipient to install client software. For most clients that worked. For roughly 5% it did not: their own IT security policies blocked the install, or the recipient could not get the software approved. Those clients sat two to three days past their delivery date, unable to reach files they had already paid for.
“We're two to three days past when we deliver a project and they can't get to the files.”
The cost did not stop at the late delivery. Resolving each access failure fell to the modeling and client success teams, whose job is producing deliverables, not troubleshooting a client's firewall. And because the barrier was the client's own security policy, it repeated. GPRS's recurring customers run many jobs a year, and a client blocked by its own install policy hit the same wall on every delivery. GPRS could tune its own tooling forever and never change the one thing the failure depended on: software approval inside somebody else's IT department.
Two Merged Teams, Two Delivery Platforms
Across the combined company, that client-side problem sat alongside a second one: the acquisition had left delivery itself split in two. One team delivered through Autodesk ShareFile. The Existing Conditions team delivered through Google Drive, a habit carried over from before the merger. Neither team had accounts on the other's platform, so clients of the combined company got a different experience depending on which team ran their project.
Google Drive brought a quieter problem of its own.
“We used Google Drive, which had unlimited storage, and so we never revoked the sharing because it didn't cost us anything to have terabytes of data up there.”
Terabytes of client data sat behind links that never expired. As Smith put it, the team "weren't as tight with security aspects because we weren't paying for it."
The obvious alternatives had already been ruled out. OneDrive had been tried for large transfers and found inadequate, and email was never an option at these file sizes. As project volume climbed toward 200 deliveries a month, a delivery model that failed at the client's firewall, split the company in two, and left shares open forever had stopped being survivable.
What the replacement had to do was clear. Deliver through nothing but a browser, because the blocked clients were blocked precisely by install policies GPRS could not change. Serve both merged teams from day one. Sit directly over the Azure Blob storage where deliverables already lived, because nobody wanted to migrate or duplicate terabytes of point cloud data. And replace open-ended shares with links that expire on a schedule GPRS sets.
GPRS selected Files.com to be that delivery layer.
A Delivery Layer Over Storage That Never Moved
For GPRS, Files.com became the single client-facing surface in front of storage that stayed exactly where it was.
Using Files.com Remote Server Mounts, GPRS connected its existing Azure Blob containers directly into the platform. The mounted folders gave Files.com a live window onto the blobs: the production pipeline kept writing deliverables where it always had while GPRS tested share links and moved client deliveries onto the new layer. Nothing migrated. Nothing was stored twice.
On top of the mount sits one identity and permission model for both teams. Users sign in through Entra ID SSO with their existing corporate identity, and a Reality Capture group with folder-level permissions decides who can see and share which projects, once, for everyone.
The client-facing piece is the Files.com Share Link. A project's deliverables go out as a link that opens in any browser, with no software and no account required of the recipient. The site carries GPRS branding, so what the client clicks looks like GPRS rather than a third-party tool. Every link expires at 90 days as standard, which closes the never-revoked-share problem by policy instead of by memory. And links are owned by the Reality Capture group rather than by individuals, so when the person who sent a share is out of the office, any teammate can find it and re-send it.
Transfers are resumable in both directions, which matters when a single project runs to 20 gigabytes. The channel runs both ways, too: clients upload files back to GPRS through the same platform.
200 Projects a Month Through a Browser Link
With Files.com in production, GPRS replaced an install-dependent handoff with a link that opens inside any client's security policy.
- Around 200 projects a month go out as browser links. The clients who used to sit two to three days past their delivery date reach their files the moment the link arrives.
- More than 5 terabytes of deliverables moved through the portal in a single month.
- Both merged teams deliver from one platform, under one GPRS-branded experience, whichever team ran the project.
- Client data is shared through links that expire at 90 days, with access administered against Entra ID, replacing Google Drive shares that were never revoked.
“Files.com gives us more control over those shares … so that we can deliver those to our clients and they're not coming back with questions like, well, I can't access this, or I can't install this.”
The modeling and client success teams got out of the access-troubleshooting business along the way.
One Company at the Point of Delivery
Today, the moment a GPRS project ships is the moment the client can open it. Delivery used to end somewhere inside the client's IT department, waiting on a software approval GPRS could do nothing about. Now it ends where it belongs: a link, a browser, the files.
GPRS did not fix client delivery by migrating storage or rebuilding its pipeline. It put Files.com in front of the Azure Blob containers it already had, and in that one move retired ShareFile and Google Drive as delivery tools and gave two acquired teams a single way to face clients. The layer clients touch changed, and the terabytes underneath it did not. For a company assembled partly by acquisition, the part clients see is now singular: GPRS's name, GPRS's governance, and one link that opens.
Related Customer Stories
Manufacturing
Porsche Cars North America Built a Files.com Alternative to Email and FileZilla That Teams Adopted Without Promotion
To clear Porsche AG's hosting rules, the channel combined federated identity, Porsche branding, and Canadian data residency for workflows across the business.
Read story →
Manufacturing
Qualcomm Uses Files.com for Modem-Log Collection Across Three Simultaneous Carrier Assessments
A shared collection layer let contractor teams upload multi-gigabyte handset logs without VPN access while Qualcomm kept its analysis systems on-prem.
Read story →
Manufacturing
Acer America Retired Its Warranty Repair FTP Server With Files.com—Without Changing the Address
A weekend cutover moved the repair channel to Files.com while preserving the Acer endpoint and protocols its service providers already used.
Read story →