Carlisle Replaced FileZilla on Microsoft Windows Server 2012 With Files.com—Without Moving the Share

Carlisle Companies has made building envelope products for over a century. At the group’s German subsidiary, Carlisle Construction Materials GmbH, known internally as CCM, file exchange with external customers had grown up the way it does at most manufacturers: on a Windows server in the building. One Windows server, in fact. And that server was running out of time.

That server held the Windows share employees used through File Explorer and ran the FileZilla FTP service external customers used to reach the same folders. CCM needed to retire it without migrating the share or changing how either group worked.

One Server, Two Jobs, and an End-of-Life Operating System

For years, a single Windows Server 2012 machine at CCM did two unrelated jobs at once. Inside the company, it served the Windows file shares that about ten CCM staff worked through Windows File Explorer every day. Outside, it ran a FileZilla FTP server exposed to the internet, which three external customers used to read and write files in the same folders.

The FTP service itself had run for years without problems. The machine underneath it was the problem: an operating system past its end of life, on aging hardware, connected to both the intranet and the internet at the same time. It had to be decommissioned.

That is where the cost sat. Retiring the server threatened two working workflows belonging to two different groups of people, because both groups worked on one set of data through two different doors. A customer writes a file from outside, and internal staff pick it up in File Explorer. Staff drop a file on the share, and the customer downloads it over FTP. Operations had to keep passing through in both directions, or one side’s work would stop reaching the other.

The obvious replacements each broke one side. Standing up a new FTP server on newer hardware would rebuild the same architecture and leave CCM operating and patching an internet-facing box indefinitely. Moving the data into a cloud file service would keep the customers connected but take the drive away from the internal team. CCM’s stated design constraint ruled that out: internal users had to keep working the share exactly as they did on the old drive, with no retraining.

Keep the Drive for Staff, Keep FTP for the Customers

The replacement had four requirements. Internal staff had to keep working the share through Windows File Explorer, unchanged. The three external customers had to keep connecting over FTP to the same folder structure they already knew. Operations had to pass through in both directions because both populations worked on the same data. And CCM had to stop running an internet-facing server of its own.

CCM selected Files.com to be that external endpoint, with the existing Windows share connected behind it.

The Agent Connected the Share, and Files.com Became the Endpoint

CCM’s own systems administrator designed the architecture and implemented it self-service, with documentation and support guidance from Files.com.

The internal share moved to a subdirectory on a current Windows server, arranged so that in File Explorer it read like the old drive. Using the Files.com Agent, CCM connected that share into Files.com as a Remote Server. The Agent ran alongside the share and held an outbound-only connection to Files.com, so no inbound firewall port opened and no machine at CCM faced the internet. The share appeared as a folder on the Files.com site, and operations passed through in both directions: a file a customer wrote from outside landed on the internal share, and a file staff saved internally was there for the customer to collect.

On the Files.com side, CCM created accounts for the three external customers and managed their access rights there, scoped to the folders each customer used. The customers connected over FTP to the same folder structure they always had. Their clients and daily habits stayed as they were. What changed was what answered the connection.

The 2012 Server Is Gone and Nobody Changed How They Work

With the Files.com connection in production, CCM decommissioned the Windows Server 2012 host, and the FileZilla service went with it. An internet-facing server the company had to own and patch was replaced by a hosted endpoint it configures.

• The aging dual-homed server is out of service. External file exchange no longer terminates on hardware inside CCM’s network; it terminates on Files.com.
• Internal staff kept their exact workflow. The share still opens in Windows File Explorer and still reads like the old drive, and nobody was retrained.
• The external customers kept theirs. They work in the same FTP folders they always did, now served by Files.com, with each customer’s access managed centrally on the platform.
• Nothing was migrated. The data stayed on the Windows share where it already lived.

Because Files.com now stands between the customers and the storage, the storage can change again later without the customers noticing. The next hardware refresh is a reconnection behind the platform, not another project that puts two workflows at risk.

Only the Door Moved

Today, a customer connects over FTP and writes a file, and a CCM colleague opens it in Windows File Explorer the way they have for years. The share stayed where it was. Files.com replaced the one piece that actually had to go: the door to the outside.