An Enterprise Software Vendor Replaced SolarWinds Serv-U With a Scripted Files.com Portal for Hundreds of PLM Customers

An enterprise software vendor makes a product lifecycle management platform for large, complex manufacturers. Its subscription model pairs heavily customized customer deployments with support, updates, and upgrades performed by the vendor itself.

That model has a consequence for infrastructure. Delivering PLM as a service relationship means the vendor's professional services and support teams work directly on customer systems. A customer's database comes to the vendor, gets packaged and upgraded version by version, and goes back. Support receives a copy of a customer's instance, stands up the same environment locally, and shares the fix back. These files run to terabyte scale, they carry customers' product data, and they move constantly between the vendor and hundreds of subscriber companies. File exchange is not adjacent to the vendor's business. It is how the product gets delivered.

Twenty Years of Customer Exchange on One Co-Located FTP Server

For 15 to 20 years, that exchange ran on an on-premises Serv-U FTP server in a co-location facility, and it ran by hand. Getting files to a customer depended on individual employees: someone created the company's folder and sent that company its access by hand.

Nearly everything moving through the system was customers' product data, and the vendor wanted it on one governed path.

By late 2024 the server was moving tens of terabytes a month.

The server was load-bearing. Its folder tree encoded twenty years of customer relationships and departmental structure, hundreds of companies had built their workflows around it, and professional services and support exchanged customer databases through it daily. There was no quiet moment in which to replace it.

Looking for a Long-Term Play, Not Another FTP Server

The pressure was structural. Volume kept climbing, and the co-located hardware was aging past what the company wanted to own.

The vendor was not shopping for a newer FTP server.

Every external user needed a named account of their own. Every subscriber company needed its own folder tree, separated by department, and internal access had to come from the corporate directory. Every action needed a record that could feed the security team's monitoring. Transfers of a terabyte or more had to finish reliably. And hundreds of customer companies had to keep working through the entire transition.

The vendor selected Files.com to replace the server outright and retire the co-located hardware behind it, rebuilding the exchange as a governed portal whose folders, accounts, and permissions could be created by script.

A Governed Portal, Built by Script

What the vendor built on Files.com is a per-customer exchange portal: one folder hierarchy per subscriber company, one named account per external user, and permissions decided by directory membership.

The structure went in programmatically. Using the Files.com CLI, the team created hundreds of company folders, each with departmental subfolders; at that scale, they were explicit that nobody was going to build the tree by hand. Internal access comes from groups pushed out of Okta through the Files.com SSO integration, with group permissions applied recursively across the tree, so what an internal team can reach is a function of directory membership.

External access got the same treatment. Subscribers and partners connect as named users, several hundred of them, permissioned in bulk against the Files.com permission report rather than one screen at a time. Managers and project leads carry accounts of their own purely for visibility into what their customers upload.

The heavy transfers that define the business run through the Files.com desktop app, whose multi-threaded uploads and downloads carry the terabyte-scale databases and instance packages that professional services and support exchange with customers. And every action lands in per-user, per-folder activity history, with audit logs streaming into Azure Sentinel through the Files.com SIEM integration.

The Structure First, the Data Sync Last

The staged implementation ran for roughly nine months, from initial architecture work in August 2024 to external customer go-live in May 2025. The migration was staged so that the structure existed before any customer depended on it. Okta SSO, share links, inboxes, and branding came first. The folder topology was designed and piloted with a single department before being applied estate-wide. The company folders and external accounts were created and permissioned by script while the old server kept running.

Only then came the cutover: a final sync from the legacy FTP server, whose single tree had grown to thousands of folders, most of them empty. Only the populated folders came across. The vendor went live with external customers in May 2025, and the co-located server was retired.

A Retired Server and a Record of Every Action

With the final sync done, the vendor runs customer exchange as a governed portal with a record of every action.

• Files reach a customer through that customer's own folder and named accounts, and every upload and download is recorded and streamed to Azure Sentinel.
• Every customer company moved off the legacy server without disruption to their work.
• The co-located server and twenty years of accumulated FTP infrastructure are gone.
• Onboarding the next subscriber company is a scripted folder tree and a named account.

Usage has grown many times over since the rebuild began, with hundreds of accounts across the vendor and its customer base and single-day transfer spikes running into multiple terabytes. The platform absorbed all of it without anyone rebuilding anything.

Rebuilt Infrastructure, Not a Newer Server

Today, the exchange that delivers the platform to its subscribers runs through Files.com: the customer databases in, the upgraded instances back out, under named accounts and a complete record.

The lesson in the cutover is worth stating. A twenty-year FTP estate serving hundreds of external companies did not move in a weekend of heroics. It moved because the vendor rebuilt the structure first: the folders, the accounts, and the permissions, all by script, tested while the old server kept running. The data sync came last, so the cutover was a sync into a portal that already worked. What used to be a workflow individual employees performed, one folder and one hand-off at a time, is now infrastructure the business governs.