A Homebuilder Retired Its Legacy FTP Endpoint Without Rewriting Vendor Scripts

A national US homebuilder sells homes through several brands, with operations in dozens of markets across the country.

Homes at that scale are sold to buyers, and buyers begin as leads. Many of the homebuilder'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 the homebuilder 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 FTP server speaking implicit FTPS, and every vendor reached it through a hand-written upload script. Almost all of its traffic was other companies' scripts, which meant the homebuilder's infrastructure team kept an aging server patched and reachable almost entirely for the benefit of outsiders.

The server survived because retiring it was never the homebuilder's decision alone. Every vendor script was written against that server, and the homebuilder 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 the homebuilder 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 the homebuilder would patch or expose the next server. And it had to wall each vendor into its own space and answer only known addresses. The homebuilder 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. The homebuilder 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, the homebuilder built the endpoint to look like its own infrastructure while accepting whatever each vendor already ran. Scripts point to a company-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.

The homebuilder 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 the homebuilder's own cloud storage with no one touching them.

The Server Came Down on the Homebuilder's Schedule

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

• The legacy FTP server was retired with every vendor script intact. A retirement that had been hostage to outside development schedules finished on the homebuilder's timeline instead.
• The homebuilder 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 the company 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.

From a Server IT Ran to a Service Teams Ask For

More than seven years on, Files.com still carries the homebuilder'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 legacy server came down on the homebuilder'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.