An IT Services Provider Replaced Its Former Parent's FTP Service and IBM Sterling File Gateway Without Rewriting Batch Jobs

A global IT infrastructure services provider designs, runs and modernizes mission-critical systems for large enterprises, and its deep mainframe practice operates the systems behind banks, insurers, healthcare systems, retailers and airlines.

Managing a client's mainframe estate is, among other things, a continuous file exchange. Software packages, PTFs, license files and OEM maintenance flow out from the provider's mainframes to the client mainframes it manages. Dumps, usage telemetry and TADz measurement reports flow back. One mainframe pushes, many mainframes pull, and the batch jobs on both ends run largely without people.

The provider was spun out of a larger parent company. On day one of its independence, the machinery carrying all of that traffic belonged to the company it had just left.

The File Transfer Backbone Belonged to the Former Parent

Before the separation, the provider's mainframe file movement ran on the parent's own FTP service, with IBM Sterling File Gateway acting as the bridge between mainframes. Every managed client estate depended on the same paths: the same directories delivered maintenance to a bank's z/OS systems and collected measurement reports from the estates the provider managed.

The transition services agreement that governed the separation put a hard end date on every connection into the parent's systems. When that date arrived, the FTP service and Sterling would be gone, and with them the mechanism by which the provider delivered software to its client estates.

Client Firewalls, Isolated Mainframes, and a Fixed End Date

The obvious fixes did not fit. Standing up another internet-facing SFTP server, the former parent's approach, was off the table: the provider had committed to a SaaS-first strategy and was not going to rebuild the problem in its own data center.

The endpoints made everything harder. The provider's clients are mainframe shops, and mainframe shops are reticent to open firewall ranges; asking each one to whitelist a rotating set of cloud hostnames, IP addresses and certificates was never going to be acceptable. Some of the provider's own internal mainframes had no direct internet access at all, reachable only over the company's internal backbone. Certificates on z/OS are loaded by hand into RACF keyrings. And batch jobs across client estates pointed at fixed legacy directory paths, so rewriting that JCL client by client was not a project that fit inside the deadline.

The replacement had to present one stable hostname under the provider's own name, backed by a small fixed set of IP addresses each client firewall team could approve once. It had to speak the protocols z/OS already spoke. It had to carry the old directory structure so existing jobs could be repointed instead of rewritten. It had to keep every client's data apart from every other's. And it had to run as SaaS rather than as another box to operate.

The provider selected Files.com to be that layer: the transfer service between its mainframes and its clients' mainframes, controlled by the provider instead of a former parent.

One Hostname, Two Fixed IPs, and the Old Paths Remapped

The provider mapped a custom domain under its own name to its Files.com site, and Files.com issued two dedicated IP addresses immediately so client firewall teams could begin their changes. From then on, every client connection pointed at the provider's hostname and two fixed addresses, whatever sat behind them.

The legacy directory tree was remapped one-for-one onto Files.com folders. A batch job that pulled maintenance from a given legacy path pulled the same path on the new host: the JCL changed a hostname, not a workflow. The legacy service ran in parallel through the transition, and the Files.com side went live ahead of the shutdown.

The z/OS estate connected over protocols it already had: FTPS with TLS client certificates, SFTP through z/OS OpenSSH, and HTTPS. The provider's own z/OS teams added static routes through the internal backbone so isolated internal mainframes could reach Files.com. Existing FTP API and Tectia batch jobs continued to run unattended.

Each managed client got its own folder, isolated with Files.com folder-level permissions. General accounts are write-only, so a client estate can deposit its reports without reading anything, and read access is reserved to superusers. One site serves every client, and no client can see another.

Multi-Gigabyte Dumps Moved Unattended

With the cutover complete, the provider had replaced the former parent's FTP service and IBM Sterling File Gateway with a single transfer layer it controls, and that layer now runs the mainframe practice's file movement day to day.

Software delivery and report collection for the client mainframe estates the provider manages—spanning banks, insurers, retailers and manufacturers—all run from one Files.com site, with each client's data walled into its own folder. z/OS batch jobs push software out and pull telemetry back with nobody handling a file.

Multi-gigabyte mainframe dumps move routinely, uploading from z/OS in minutes. Bringing the next client estate onto the pattern means a per-client folder and one firewall change against the same two fixed addresses, not a new integration.

The layer also carries centralized governance. Users are provisioned from Okta over SAML with SCIM, so access follows the corporate directory. Sitewide IP allowlisting was rolled out under an internal security mandate, and history logs are retained for a set period for audit. The Office of the CIO, which now owns the platform, extracts data from Files.com to build the KPI metrics presented to executives in monthly operational reviews, so the file transfer layer is measured like the rest of the business.

The Mainframe Workflows Did Not Have to Be Rewritten

Today, the path between the provider's mainframes and its clients' mainframes is the provider's own. An engineer distributing maintenance drops it once, and every estate that needs it pulls it on schedule. Nothing about that depends on a former parent's infrastructure or a contractual clock.

What is worth taking away is what did not change. Batch jobs written against an FTP service from another era still run; their workflows did not have to be rewritten. They point at the provider's own hostname now, and Files.com answers. Meeting a divestiture deadline did not require modernizing the endpoints. It required giving the old paths a new platform underneath them, and Files.com is what that platform turned out to be.