PulteGroup Retired Its Microsoft Windows Server 2008 FTP Endpoint Without Rewriting Vendor Scripts

PulteGroup is the third-largest homebuilder in the United States. Through brands including Centex, Pulte Homes, Del Webb, and DiVosta, the company delivered nearly 30,000 homes in 2025, with operations across more than 45 markets in 26 states, and it has built more than 875,000 homes since its founding.

Homes at that pace are sold to buyers, and buyers begin as leads. Many of PulteGroup's leads arrive as files: outside marketing vendors deliver lead files to the marketing team as a standing part of how the company sells. That makes file exchange with companies PulteGroup does not control a structural fact of the business, and for years it all ran through one server.

Retiring the Server Meant Waiting on Every Vendor's Developers

That server was an in-house Microsoft Windows Server 2008 FTP server speaking implicit FTPS, and every vendor reached it through a hand-written upload script. Only a handful of people inside PulteGroup touched the service. The majority of its traffic was other companies' scripts, which meant PulteGroup's infrastructure team kept an aging Windows server patched and reachable from the internet almost entirely for the benefit of outsiders.

The server survived because retiring it was never PulteGroup's decision alone. Every vendor script was written against that server, and PulteGroup does not write its vendors' code. Any replacement that changed the protocol or the connection behavior meant each vendor's developers rewriting their upload scripts, on their own schedules. When PulteGroup asked one vendor for a new SFTP script, the answer was that it could not be written until the summer. Across a whole roster of vendors, the retirement date belonged to the slowest development backlog on someone else's payroll.

So the goal was stated plainly: get the vendors off the in-house server. The replacement had to accept every existing script exactly as written, which meant speaking FTPS in both implicit and explicit modes as well as SFTP, and behaving the way each script expected. It had to be hosted, so nobody at PulteGroup would patch or expose the next server. And it had to wall each vendor into its own space and answer only known addresses. PulteGroup selected Files.com as that endpoint.

An Endpoint That Met Every Script Where It Already Was

The first vendor to move proved the model. That vendor uploaded through a PHP script driving cURL, written against the old server. PulteGroup pointed the script at Files.com, resolved the connection in passive mode, and the script worked unchanged. The vendor's developers were never involved, and the cutover closed in early 2019.

Behind that cutover, PulteGroup built the endpoint to look like its own infrastructure while accepting whatever each vendor already ran. Scripts point to a Pulte-branded custom domain and connect over FTPS, SFTP, or the Files.com REST API. Each vendor lands in its own home folder, isolated from the others, while per-user IP whitelisting limits connections to expected addresses.

PulteGroup treats the endpoint as production infrastructure. Microsoft System Center Operations Manager runs a synthetic check every five minutes: it connects, writes a file, verifies the file was written, then deletes it, and a failed connection raises an alert. And files that land do not wait for a person. A scheduled Files.com sync pushes arriving files onward to Azure Blob Storage on a short interval, so vendor drops flow into PulteGroup's own cloud storage with no one touching them.

The Server Came Down on PulteGroup's Schedule

With vendor traffic on Files.com, PulteGroup replaced a server its own team had to run with an endpoint nobody at the company maintains.

• The Windows 2008 FTP server was retired with every vendor script intact. A retirement that had been hostage to outside development schedules finished on PulteGroup's timeline instead.
• PulteGroup no longer operates an internet-facing FTP server at all. The endpoint is Files.com's to run, and SCOM confirms every five minutes that it is up.
• Onboarding the next vendor is a scoped folder and a credential, on whichever protocol the vendor already uses. One vendor connects programmatically over the Files.com REST API with an API key.

The larger change came after the cutover. Within months, development teams inside PulteGroup were asking for the service, and what began as a vendor endpoint became something internal teams build on. A Power Automate integration authenticates with an API key and pulls files down over the REST API, promoted through development, pre-production, and production environments.

“Your service has proven to be one of the best decisions we have made.”

From a Server IT Ran to a Service Teams Ask For

More than seven years on, Files.com still carries PulteGroup's vendor file exchange. The ask that used to define this workload—asking an outside company's development team for time—no longer exists.

The Windows 2008 server came down on PulteGroup's schedule because Files.com met every vendor where its scripts already were. The old server never needed a single user to change before it could go.