A Fleet Services Provider Replaced Progress WS_FTP With Files.com Without Breaking Hundreds of Live Customer Connections

A commercial fleet services provider runs a weigh-station bypass and toll payment service across North America. Commercial vehicles in fleets of every size use it to clear weigh stations at highway speed.

That service runs on data moving in both directions. Bypass decisions rest on carrier safety scores, credentials, and inspection history. Fleets, in turn, collect their own operational and financial files from the provider: activity reports, tolling data, billing files. Every customer needs a secure account of its own to pick those files up. File delivery, at the scale of the entire customer base, is part of the product the company sells.

The result was more than a successful migration: Azure B2C logins now provision the corresponding file accounts on Files.com, creating a delivery model that can keep expanding with the company's customer and contractor base.

Customer Delivery Had Outgrown Progress WS_FTP

The company delivered those files over Progress WS_FTP, and the business had outgrown it. Secure delivery was needed for hundreds of individual SFTP accounts at the start, covering both automated B2B exchange and individual customer logins, with the base growing continuously. Demand was compounding from an unexpected direction too: customers' own third-party contractors wanted access to the same data files, and every contractor meant another account to create.

What the replacement had to do describes what WS_FTP was not doing. One platform had to cover both populations. It had to absorb every existing account with headroom well past that. It had to run under the company's own domain and branding, and meet the IP restriction, audit-retention, and availability requirements that operational and financial data carries. The sharpest requirement was identity: the company's customers sign in through Azure B2C, Microsoft's consumer identity platform, and the company needed file accounts driven by those logins rather than created and managed as a separate set of credentials. Without B2C integration, there was no viable replacement at all.

And the old estate could not simply be switched off. Hundreds of live customer connections pointed at the server: automated jobs, scripted downloads, saved client configurations. The SFTP host key could not be exported from WS_FTP, so any move meant every connecting customer would see an unfamiliar server fingerprint. The legacy directory tree was organized by customer name, with ingestion jobs wired to those folder names, so users could not even be created in bulk until the structure was standardized.

Consumer Logins That Create Their Own File Accounts

The company selected Files.com to replace WS_FTP as the delivery layer for both populations. On Files.com, the delivery platform stopped being a standalone credential store and became an extension of the identity system customers already use.

The company connected Azure B2C to Files.com's SAML single sign-on with just-in-time provisioning. When a customer signs in with their B2C identity, Files.com creates the matching user automatically. A customer's file account no longer has to be built before the customer can use it: the login itself provisions it.

A Parallel Migration Around a Host Key WS_FTP Would Not Give Up

The migration ran in parallel with WS_FTP rather than as a single cutover. Prerequisites came first. The legacy directories keyed by customer name were renamed to account IDs, and the database team repointed every ingestion and import job at the new folder names, so users could be created against a standard structure. Files.com's bulk user import then staged the migrating accounts in one template.

The company put the new endpoint under its own branded domain, with the dedicated IP addresses that come with it, so customers who allow traffic by address had fixed addresses to allow. Since WS_FTP would not export its host key, the company installed a custom SFTP host key on Files.com and sent the new fingerprint out with the connection details, with account managers walking each customer through the change.

The sequencing did the rest. B2C customer accounts moved first. The B2B processes running against partner-controlled remote servers followed. WS_FTP stayed available to accounts that had not yet moved, so the hundreds of live customer connections kept operating through the phased migration.

New Customer Accounts Every Sprint

With WS_FTP retired, the company replaced a hand-managed delivery estate with a platform that grows at the pace of its customer base.

• For B2C customers, logging in now creates the file account instead of requiring the company to build it in advance. Onboarding has continued with new customer accounts every two-week sprint since the migration, so the delivery layer no longer constrains taking on customers.
• Contractor demand is absorbed instead of resisted. Each customer's third-party contractors get accounts of their own against the same data, on the same platform, under the same controls.
• The Files.com site has kept growing as customer, contractor, and internal adoption continued.
• Internal teams followed the customers onto the platform. Site systems at hundreds of weigh-station locations, along with HR and Finance, now move files through the same Files.com site, with automations running on their data.

The Estate That Looked Too Connected to Move

File delivery at the company used to be a server: hand-provisioned, organized around folder names from another era, and holding its own host key where nobody could reach it. Today it is part of how the company takes on customers. A new fleet signs in with the identity it already has, its Files.com account exists the moment it does, and it collects its reports the same way as the hundreds of customers before it.

The migration is the portable lesson. The company never held a synchronized cutover. It ran Files.com in parallel with WS_FTP, moved consumer accounts first and partner-run server processes after, and treated the one thing the old server refused to surrender, its host key, as a fingerprint in a customer communication rather than a blocker. A legacy FTP estate with hundreds of live connections hanging off it turned out to move one phase at a time.