Skip to main content

PulteGroup Cut File Copies From 2 Minutes 20 Seconds to 4 Seconds by Replacing NetApp Cloud Volumes ONTAP SMB With Files.com

A pilot kept familiar drive letters and demanding Excel workflows intact while moving remote file access from latency-sensitive SMB to HTTPS.
PulteGroupFiles.com

PulteGroup is one of the largest homebuilders in the United States, with operations spanning more than 45 markets across 26 states.

Homebuilding is local work, so PulteGroup runs as dozens of geographically distributed market offices. Roughly 6,200 employees work out of those markets and the corporate office, and the files their days run on sit on shared drives: Office documents, PDFs that get signed, and large Excel files that pull data from other systems, about 180 TB in all. As the company moved that storage into the cloud, every market office ended up on the far side of a long network path from every file it touched.

Every Market Office Was 80 Milliseconds From Its Files

Market file storage ran in two generations. About a thousand employees, mostly on the East Coast, worked from NetApp Cloud Volumes ONTAP shares hosted in Azure. The other five thousand or so worked from Windows file servers in the offices themselves. Both were reached the same way: SMB shares mapped to drive letters through Group Policy, with NTFS permissions maintained by hand.

The local servers were fast, because SMB works when the files are down the hall. The cloud shares were not. Latency from the market offices to the NetApp shares measured 80 to 90 milliseconds, and SMB does not absorb latency. It multiplies it.

Latency affects it exponentially. It's a very chatty protocol.
John Casella, Lead Infrastructure Architect, PulteGroup

The tax showed up in ordinary work. Copying 100 MB of mixed files to the cloud share averaged 2 minutes and 20 seconds. Adobe PDF signing failed 50 to 60 percent of the time against a file on cloud SMB, while the same operation on a local file succeeded every time. The heaviest users had it worst: large Excel files with OLAP integrations pulling data from other sources were the most troublesome workload in the markets. People had largely stopped reporting any of it. Slow had become how the shared drive worked, and productivity in the markets paid for it every day.

The storage was healthy and the network was ordinary. The problem was the protocol between them.

The Fix Could Not Be Another Server

The easy answer, keeping files on servers in the offices, was the one answer not available. PulteGroup's direction, set at CTO level, was SaaS-first: serverless in the markets, internally managed systems retired. An earlier run at that goal had stalled about a quarter of the way through the rollout, so the servers the company intended to eliminate were still doing most of the work.

Tuning could not rescue the cloud shares either. The path from a market office into Azure crossed networks PulteGroup did not control, so hop counts and routing were never theirs to engineer. Extending the NetApp shares to the whole company would only put more users onto the taxed path.

What the replacement had to do was specific. Keep everything users and their applications touched: the drive letters, the folder structure, Office editing with locking, PDF signing, the big Excel models. Take SMB, and its sensitivity to distance, out of the path entirely. Require no hardware in the offices. And leave open where the data actually lived.

PulteGroup selected Files.com to deliver that: the same mapped drives, carried over HTTPS instead of SMB.

The Same Drive Letters, Carried Over HTTPS

The Files.com Desktop App presented each user's drives in File Explorer on Windows and Finder on Mac, exactly where the Group Policy mappings used to be. Files streamed in when opened, cached locally, and saved back on close, and every operation traveled over HTTPS instead of SMB's per-packet round trips, so latency stopped compounding with each transaction.

Using Files.com desktop configuration profiles, PulteGroup centrally deployed each market's existing drive mappings by group, with individual exceptions where needed and no office hardware to install. Sign-in ran through Microsoft Entra ID single sign-on, so file access followed the corporate directory.

The folder tree was organized by market, with each market carrying the equivalent of the group and shared drives its people already knew. Behind the folders, PulteGroup ran both Files.com native storage and its own Azure Blob Storage, connected as a Files.com remote server. The drive letter was identical either way, which turned the question of where the data lived into a backend decision users never saw.

PulteGroup deployed the model to a pilot cohort of roughly 50 users, sequenced to prove the hard part first. Internal IT teams went on the drives before anyone else. The next wave deliberately targeted the users who had complained the most: the ones working the huge OLAP-connected Excel files, chosen because theirs was the most network-sensitive workload the markets had.

Seconds Instead of Minutes, and Signatures That Complete

With the Files.com drives in the pilot, participants stopped reaching their files over SMB, and the distance tax went with it.

It took an average of 2 minutes and 20 seconds. To the map drive to Files took 4 seconds.
John Casella, Lead Infrastructure Architect, PulteGroup

The rest of the results followed the same line:

  • Document signing became reliable. PDF signing, which failed 50 to 60 percent of the time over cloud SMB, ran from the Files.com mapped drive the way it ran against a local file.
  • The hardest workloads passed. The heavy Excel users did their real daily work from the new drives, OLAP integrations included, with Office documents locking on open through Files.com file locking.
  • Files.com came out ahead in preliminary testing. The team's tests put its mapped drive ahead of both the NetApp shares and direct Azure Blob access.
  • The model required no new office hardware. A market's drives came from a configuration profile pushed from the server, not a server installed in the office and refreshed on a hardware cycle.

A Serverless Path for the Markets

Today, an employee in the pilot opens the same drive letter they always have. What changed is everything behind it. Every touch on a file used to pay for the distance to it: copies ran to minutes, signatures failed more often than they completed, and people had stopped complaining because slow was simply the deal. Now Files.com carries the file over HTTPS, the copy takes seconds, and the signature completes without depending on cloud SMB.

The pilot did not retire every market server. It proved the operating model PulteGroup needed and established a market-by-market path for moving the wider estate while preserving the drives and workflows employees already knew.

PulteGroup did not get there by tuning storage or re-engineering networks it did not control. It replaced the protocol. Cloud file storage does not have to speak SMB to look and act like a file server: with Files.com, the drive letters stayed and the latency left.