Skip to main content

A Global Supply Chain Company Moved Hundreds of Partner Connections Onto One Key-Authenticated SFTP Endpoint on Files.com

Because connection details sat with hundreds of outside companies, the company replaced an all-at-once migration with scheduled, service-by-service cutovers.

A global supply chain management company manages sourcing, warehousing and distribution for hundreds of brands, moving millions of orders a year through distribution centres across Europe, Asia and North America.

An operation like that runs on data as much as on trucks. Orders, invoices and shipping documents move constantly between suppliers, distribution centres and the company's ERP, and hundreds of external companies exchange files with it every day. For years, that exchange ran through FTP and SFTP servers the company operated in its own data centre.

Hundreds of Live Connections on Servers the Company Wanted to Retire

The company's technology organization planned to exit the data centre, and the file transfer estate had to move with it: hundreds of SFTP and FTP connections serving suppliers, distribution centres and partners. This was not dormant legacy. A single server in the estate carried thousands of transfers a day.

The company set the target for what came next: one protocol in place of two, every external connection on key-authenticated SFTP under its own name, and no virtual machine hosts of its own to keep patched.

Hundreds of Connections the Company Could Not Change by Itself

The hard part was structural: the connections belonged to other companies. Every supplier, distribution centre and automated bot account pointing at those servers held its own connection details, and the company could not update a single one of them on the counterparty's behalf. The data flowing through was live transactional pass-through, orders and invoices in flight between suppliers and the ERP, so there was no quiet window to take the service down. A synchronized cutover of hundreds of external connections was never realistic.

What a replacement had to do followed directly from that constraint. It had to be a hosted endpoint that external parties could reach over the protocols they already used. It had to carry the company's own name, so a supplier updating connection details would still be connecting to the company rather than to a vendor's subdomain. And it had to absorb a staged migration: services moving one at a time over months, with the old and new estates running in parallel, ending on a single key-authenticated SFTP standard.

The company selected Files.com as the platform the estate would collapse onto.

One Service at a Time, With a Hard Cutover Date for Each

A dedicated project manager then ran the migration in parallel, service by service. Each service got a hard scheduled cutover date, and its external users got advance notice to update their connection details to the new endpoint: a Files.com site fronted by the company's own domain, so what a counterparty saw was the company's name, not Files.com. Because the data on the legacy servers was transactional pass-through, there was no archive to move. When a service cut over, its counterparties repointed and its traffic started flowing through Files.com.

The move was also a consolidation. The FTP connections converted to SFTP on the way across, collapsing two protocols into one, and external bot accounts moved to SSH-key authentication only.

One Protocol, One Domain, and Nothing Left to Patch

With the services cut over, the company had replaced a two-protocol server estate that hundreds of external companies depended on with a single hosted SFTP endpoint under its own domain.

  • The last file-transfer dependency on the data centre was gone, and the exit could proceed.
  • Hundreds of supplier, distribution-centre and partner connections now run on one Files.com site over SFTP alone, one protocol in place of two.
  • Machine-to-machine accounts authenticate with SSH keys only, so no automated connection depends on a password.
  • The virtual machine hosts and their patching retired along with the servers.

The migration completed as a sequence of scheduled cutovers, none of which required the rest of the estate to move at the same time.

File Transfer Off the Critical Path

Companies planning a data centre exit write migration plans for their applications. This exit shows that the file transfer estate underneath those applications is often what actually anchors the building, because its connections belong to other companies. It still does not have to move as one event. The company moved it one service at a time, and when the last service cut over to Files.com, the last reason to keep the data centre went with it.

Get The File Orchestration Platform Today

4,000+ organizations trust Files.com for mission-critical file operations. Start your free trial now and build your first flow in 60 seconds.

No credit card required • 7-day free trial • Live in minutes