Carlisle Companies Connects an On-Premises File Share to a Hosted FTP Endpoint With Files.com

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 server in the building. One server, in fact, serving staff inside and customers outside.

That server held the file 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 Two Groups of Users

For years, a single server at CCM did two unrelated jobs at once. Inside the company, it served the file share that about ten CCM staff worked through File Explorer every day. Outside, it ran the FileZilla FTP service a few external customers used to read and write files in the same folders.

The FTP service itself had run for years without problems. The server underneath it was what CCM wanted gone: a machine the company had to own and patch itself so that customers could reach it from outside.

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 File Explorer, unchanged. The 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 file 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 file 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 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 Old Server Is Gone and Nobody Changed How They Work

With the Files.com connection in production, CCM decommissioned the old server, 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 old server is out of service. External file exchange terminates on Files.com, not on hardware inside CCM’s network.
• Internal staff kept their exact workflow. The share still opens in 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 file 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 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.