In Your Own Bucket
A Remote Server Mount writes every upload straight through to your Amazon S3, Azure Blob, or Google Cloud storage. Partners speak SFTP; the bytes live where your pipelines already read.
Files.com takes over the hostname, the host key, and the credentials your partners already use, so the server behind them can be retired without a cutover weekend. Vendors, clients, and scheduled jobs keep connecting to the address they have. Only the box behind it changes.
The server was never the hard part to replace. The hundreds of scripts, firewall allow-lists, and pinned host keys pointed at it are, and every one of them belongs to someone who will not act on your schedule. That is why the old server is still running.
Every outside connection to a file-transfer server is bound to four things: a hostname, a host key, a credential, and an IP address. A partner’s nightly script has them baked in. A counterparty’s firewall allows one of them. A device installed years ago cannot be re-credentialed from the outside at all.
Meanwhile the server itself is patched, licensed, exposed in a DMZ, and understood by one person. Rebuilding it on new hardware buys another decade of the same work. Moving to a new address means a cutover coordinated with every counterparty at once. Files.com carries the four things partners depend on across the move, which is what makes the server itself disposable.
Real companies. Real file flows. Real results.






















The four things a partner’s connection is bound to, and how each one moves to Files.com unchanged.
A custom domain puts your Files.com site behind the address partners already have. The cutover is a DNS change, and the next connection to your own SFTP hostname lands on Files.com instead of the box.
Files.com can present the SSH host key your server has always used, imported from the old server. An SFTP client that has pinned your key connects without a changed-host-key warning, so no partner has to touch a known-hosts file.
Bulk Import creates the accounts from a CSV, and each one can carry its existing password hash. Files.com verifies the hash on the first login and re-stores it, so partners keep the credential they have. SSH keys and per-user IP allow-lists come across the same way.
A custom domain comes with two dedicated IP addresses, so a partner whose firewall allow-lists your endpoint has a fixed address to allow. Enterprise sites can bring their own IP ranges and keep the allow-lists they have spent years getting approved.
No flag day. The old server stays live the whole way through, and the last step is turning it off.
Files.com connects to the old server over SFTP and a sync copies the folder structure and the files across, on a schedule, while the server keeps serving.
Import the users with their password hashes, keys, and allow-lists, and set each one into the folder it already has. Nine permission levels reproduce whatever access model the old server enforced.
A child site on a separate subdomain is the test environment. Partners who want to test connect early. Nothing is retired until the flows you care about have run on Files.com in production.
Point the hostname at Files.com in a quiet window. The next upload from every partner lands on Files.com, and the server behind the address has nothing left to do. Estates with hundreds of feeds move one counterparty at a time instead, with the old server alive until the last one.
The global photo desk moved photographers individually onto a managed inbound perimeter while its cameras, internal servers and downstream publishing systems kept working as before.
Read The Story
A weekend cutover moved the repair channel to Files.com while preserving the Acer endpoint and protocols its service providers already used.
Read The Story
Amid simultaneous ERP and cloud migrations, Marc Jacobs kept dozens of live retail flows moving while completing its data-center exit.
Read The Story
Files.com runs alongside the old endpoint, letting Jockey remove workloads it controls while vendors and remaining third parties move on their own schedules.
Read The Story
“Our previous solution was on-prem, so we had to allow a third-party vendor onto our entire network. With Files.com that isn't the case — everything is handled at the cloud-based level, whether it's inbound or outbound.”

“Our FTP and SFTP protocols now run consistently without manual intervention. Fewer and fewer issues of files not going where they're supposed to.”

The endpoint moves to Files.com. The storage behind it can be ours, your cloud bucket, or the share you already run.
A Remote Server Mount writes every upload straight through to your Amazon S3, Azure Blob, or Google Cloud storage. Partners speak SFTP; the bytes live where your pipelines already read.
The Files.com Agent connects an on-premises share over an outbound-only connection. The internet-facing endpoint moves to Files.com and the files still land inside your network, with no inbound firewall rule.
Or let Files.com hold them, encrypted at rest, with per-folder retention that expires what the old server accumulated for years because nobody wrote the cleanup script.
A team retiring a file-transfer server is usually choosing between new hardware, a cloud provider’s endpoint, living with two systems, or another product it has to run. Here is where each one lands.
A new box resets the clock on the hardware and nothing else. The patching, the CVE scramble, the DMZ exposure, and the one person who understands it all come along, for another decade.
AWS Transfer Family and Azure’s native SFTP give you a port on a bucket and leave accounts, allow-lists, automation, and the audit trail for you to build. Files.com is the assembled product, in front of any cloud.
Two systems forever is the most common outcome of a migration that needs a cutover weekend. Carrying the hostname and host key over is what removes the reason to keep the old one alive.
IBM Sterling, GoAnywhere, MOVEit, and Axway are servers you run, license by module, and patch. Moving off legacy MFT runs the same sequence as this page, one workload at a time.
What infrastructure and security teams ask before retiring the server partners connect to.
Yes. Files.com serves your site under a custom domain, so the hostname your partners, scripts, and devices already use points at Files.com through a DNS change. The address they connect to does not change, only the server answering it.
No, if you import your existing host key. Files.com lets you use a custom SFTP host key, so the key your partners’ clients have pinned is the key Files.com presents. A client that would refuse an unfamiliar key connects to Files.com as though nothing changed.
No. Files.com imports existing password hashes in the common formats, including PBKDF2, MD5, SHA-256, and standard Modular Crypt Format, and verifies each hash on the user’s first login before re-storing it under its own hashing. Users keep the password they have. SSH keys come across as well.
A Files.com custom domain includes two dedicated IP addresses, one per availability zone, so partners with firewall allow-lists have fixed addresses to allow. Enterprise sites can go further and route their own public IP ranges through Files.com, so the addresses partners already allow stay in place.
Yes, and most migrations do. Files.com pulls from the old server over SFTP on a schedule while it stays live, a child site serves as the test environment, and partners move one at a time or all at once at the DNS change. Nothing is retired until the flows you care about have run on Files.com in production.
Files.com supports SFTP, FTPS, and FTP, so a partner that only speaks FTP keeps connecting. Plain FTP is disabled on a new site by default and enabled per site when you need it, which is also how you retire it later, one partner at a time, while everything else runs.
Yes. A Remote Server Mount passes every upload straight through to your Amazon S3, Azure Blob, or Google Cloud storage, and the Files.com Agent lands files on an on-premises share over an outbound-only connection. The internet-facing endpoint moves; the storage is yours to decide.
Files.com Automations take over the copy, move, route, and cleanup jobs that used to run as cron or PowerShell on the server, triggered when a file arrives or on a schedule, with retries and a log. Anything bespoke can call the REST API or one of the SDKs.
The sequence is the same, and the stakes are higher. Files.com takes over one partner flow at a time while IBM Sterling, GoAnywhere, MOVEit, or Axway keeps running the rest, until the renewal makes the retirement official. Switching off legacy MFT walks through it, and when you arrive with a competing legacy MFT quote, Files.com will match or beat it.
A single server with a few dozen accounts moves in days: mirror the folders, import the users, change DNS. Most teams are live on Files.com within five business days of starting. An estate with hundreds of counterparties moves one feed at a time over weeks or months, on your schedule rather than a cutover weekend, and the old server stays live until the last one.
Mirror the folders, import the users with their passwords and keys, run in parallel, and change DNS when you are ready. Your partners never know the server behind their connection changed. Start the 7-day free trial and connect the old server today.
No credit card required • Free for 7 days • Live in minutes