An Index Provider Moved Daily Index Distribution From Consultant-Run MFT to Files.com—Without a Cutover Day

A market index provider builds and administers indexes licensed to ETF issuers, asset managers, and index-data vendors. The company has grown largely by acquisition, and it runs index calculation and administration on its own cloud-based index engine.

An index is a methodology until it ships, and it ships as files. Every afternoon, the provider's jobs turn the day's index values into a few thousand data files, and systems at ETF issuers, banks, and index-data vendors pull those files automatically into their own pipelines. For an index provider, daily file distribution is not back-office plumbing. It is the delivery of the product.

The provider ultimately moved that live distribution layer to Files.com without a coordinated cutover day: history crossed in bulk, clients moved one at a time, and daily publication continued.

The Distribution Layer Belonged To Someone Else

That delivery ran on a custom-built managed file transfer (MFT) platform administered by an external consulting firm. The provider's own Python jobs generated the index files in its data center and pushed them to the platform each afternoon, and clients retrieved them from there. Everything upstream of the hand-off was the provider's: the methodologies and the jobs that turned them into files. The hand-off itself was one-off software the company's own team did not operate. The layer sitting between the provider and every institutional client it serves belonged, operationally, to an outside firm.

Acquisition made the arrangement untenable rather than merely awkward. When the provider acquired another index business, it inherited a second distribution estate, and that one ran on Files.com, where the acquired index series had been published to clients for years from a branded domain with dedicated IP addresses that client firms whitelisted. After the provider was itself acquired by a larger group, the combined company was maintaining two separate systems for the same class of work: one its team administered directly, and one it reached through a consultancy.

What A Replacement Had To Survive

What kept the custom platform in place was everything connected to the other side of it. The provider's clients run their own retrieval automation: in-house scripts and systems that watch per-index folders and pull new files the moment they land. One client alone polls dozens of folders every few minutes over SFTP. The provider does not build these integrations and cannot dictate how the institutions build them. They are client relationships, not systems it controls. Replacing the platform underneath that ecosystem meant moving years of historical files and shifting every client's automation to a new endpoint, with a publication run that has to land every single afternoon in between.

The requirements followed from that. The new platform had to speak the protocols the client tooling already spoke: SFTP and a REST API. It had to present stable addresses under the provider's own name that client firms could whitelist once. It had to hold the per-index folder structure the retrieval scripts point at, and it had to stand up to read traffic that runs around the clock. Above all, it had to be a platform the provider's own team administers. The provider selected Files.com, the platform already carrying the acquired index series, as the single distribution endpoint for the combined business.

A Bulk Sync And A Gradual Migration, Not A Cutover Day

A dedicated Files.com site went live under a custom domain in the provider's name, with dedicated IP addresses and the provider's CTO as site administrator.

The history moved first. In early 2024, the provider bulk-loaded its file inventory into the new site with a purpose-built sync script, and Files.com temporarily raised the site's API allocation while the backlog crossed. Once it had, usage settled into a predictable daily pattern.

Client institutions moved gradually rather than on a single cutover day. Each institution received scoped Files.com access. Because the endpoint speaks standard SFTP and the Files.com REST API, the retrieval tooling those institutions had already built carried over to it, and publication continued every afternoon throughout the transition. Within months, the consultant-run platform was sunset.

The shape of the operation did not change, which was the point. The provider's existing publishing jobs and its clients' retrieval automation continued working on either side. Files.com replaced the exchange layer and left both ends of the pipeline alone.

One Afternoon Of Writes, A Full Day Of Reads

With the migration complete and the custom platform retired, the provider traded a distribution layer it reached through a consultancy for one its own team runs on Files.com. The endpoint now absorbs institutional retrieval at a scale the publishing side barely hints at. The provider publishes once each afternoon, and its clients pull all day and night.

That control has three practical consequences:

• The provider's platform team administers users, permissions, API keys, folders, and logs directly, with no outside firm between them and a change.
• Onboarding another institutional client is now a provisioning task on the existing endpoint. The folders, protocols, addresses, and permission model are already in place, so a new client is a scoped user account, not a new integration.
• A separate data property the provider publishes, until then its own Files.com site, was later brought under the index-data site as a child site, with Files.com performing the move. Two operating environments came under one parent and one set of administrators, without a rebuild on either side.

Distribution The Provider Runs Itself

The migration disproved the fear that keeps companies on aging custom MFT: that the platform underneath live client automation can only be replaced on a cutover day everyone has to survive together. The provider preserved the protocols and folder structure, established stable addresses, moved the history in bulk, and migrated clients one at a time. The backend changed, the old platform was retired, and the scripts on the other side kept pulling.