A Utility Locating Company Replaces ShareFile and Google Drive With Files.com Without Moving Its Azure Blob Data

A US utility locating company's field project managers locate buried utilities, scan concrete, and inspect pipelines in every major American market.

What the company 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 the company acquired a reality capture firm, 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 runs to tens of gigabytes, sometimes more, and every one of them has to land inside a client's network. The company controls nothing about that network.

The acquisition also left the combined company with two client-delivery platforms. The company would use Files.com to replace 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

The company 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. For those clients, delivery stopped at the install step.

The cost did not stop there. 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. The company's recurring customers run many jobs a year, and a client blocked by its own install policy hit the same wall on every delivery. The company 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 ShareFile. The acquired reality capture team delivered through Google Drive. 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.

The company also wanted every client share to expire on a schedule it set, on a platform administered against its corporate directory.

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 hundreds of deliveries a month, a delivery model that failed at the client's firewall and split the company in two could not carry that volume.

What the replacement had to do was clear. Deliver through nothing but a browser, because the blocked clients were blocked precisely by install policies the company 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 issue every share as a link that expires on a schedule the company sets.

The company selected Files.com to be that delivery layer.

A Delivery Layer Over Storage That Never Moved

For the company, Files.com became the single client-facing surface in front of storage that stayed exactly where it was.

Using Files.com Remote Server Mounts, the company 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 the company 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 the company's branding, so what the client clicks looks like the company rather than a third-party tool. Every link expires on a standard schedule, set by policy. 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 tens of gigabytes. The channel runs both ways, too: clients upload files back to the company through the same platform.

Hundreds of Projects a Month Through a Browser Link

With Files.com in production, the company replaced an install-dependent handoff with a link that opens inside any client's security policy.

• Hundreds of projects a month go out as browser links. Clients whose security policies allow no installed software reach their files the moment the link arrives.
• Terabytes of deliverables moved through the portal in a single month.
• Both merged teams deliver from one platform, under one branded experience, whichever team ran the project.
• Client data is shared through links that expire on a set schedule, with access administered against Entra ID.

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 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 the company could do nothing about. Now it ends where it belongs: a link, a browser, the files.

The company 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: the company's name, the company's governance, and one link that opens.