An Appraisal Software Provider Makes Inherited FTP Retirement a Repeatable M&A Step—Without Re-Onboarding Municipal Customers

A government appraisal software provider serves local government assessing departments with appraisal services and computer-assisted mass appraisal (CAMA) software, from small communities to large cities. The work is governed by state law: when a state requires a municipality to reassess every property to current market value, the company's software and its appraisers are how that gets done. Assessment data, reports, and database files move constantly between the company and the assessor offices it serves.

The company also grows by acquisition. And every acquired appraisal company arrives with the same thing: its own file transfer infrastructure, carrying live traffic for its own municipal customers.

Every Acquisition Arrived With Another FTP Server

The inherited infrastructure was almost always an on-premises FTP server in the acquired company's own environment.

Each of those servers was a standing cost: another endpoint to run, and another box someone had to manage separately from everything else. The company wanted every acquired company's traffic on the platform it already governed. And because the deals kept coming, the estate kept growing faster than one-off cleanup could shrink it.

The obvious fix was worse than the problem. Decommissioning a server the normal way means moving its users to a new address with new credentials. Here, those users were entire customer bases of county and municipal assessor offices. They had pointed their clients at the same endpoint for years, and the company was not going to ask every one of them to reconfigure anything. Re-onboarding a whole customer base per acquisition was a coordination project nobody wanted to staff, multiplied by every deal.

Consolidation carried its own hazard. Folding every acquired estate into one shared environment would intermingle each company's data and customer traffic with everyone else's.

So the fix had to do three things at once: keep every customer's address and credentials exactly as they were, keep each acquired company's data in its own boundary with its own administrators, and shut the inherited server down. The company made Files.com the standing destination for all of it.

A DNS Swap, a Child Site, and the Same URL

The playbook the company built turns each inherited FTP server into a Files.com child site. The company stands up the child site, migrates the existing usernames and passwords onto it, and swaps DNS so the legacy hostname resolves to Files.com. The assessor offices keep connecting to the same URL with the same credentials they have always used. The connection now terminates on Files.com instead of a server in someone's office, and the old box gets shut down.

The child site is what makes consolidation safe. Each one is a fully separate site under the company's parent account, with its own users, folders, and administration, so the team that came with an acquisition manages its own data and its own customers. The company keeps governance over everything from the parent account, and the same playbook applies as each new deal closes.

FTP Retirement Became a Step, Not a Project

With child sites carrying the traffic, the company replaced a per-acquisition migration project with a repeatable integration step.

• Every cutover was invisible to the customers on the endpoint: no communications campaign, no credential resets, no support queue of assessor offices locked out of an unfamiliar system.
• The inherited FTP servers are shut down, and the traffic they carried terminates on Files.com.
• Each acquired estate stays segmented in its own child site, run by its own team, under one set of controls at the parent, so consolidation never meant commingling.
• The platform absorbed the growth that came with the deals. One acquisition alone roughly doubled the company's storage on Files.com, without any new infrastructure to stand up.

The Next Acquisition Already Has a Destination

The company never migrated its customers off the old servers. It migrated the servers out from under the customers. The address and the credentials outlived the infrastructure behind them, and that is what made retiring it possible at all.