Martin Brower ANZ Retires On-Premise SFTP and FTP While Preserving Partner Workflows

Martin Brower ANZ is the dedicated foodservice supply chain company behind more than 1,200 quick service restaurants across Australia and New Zealand. From eight temperature-controlled distribution centres, it warehouses and delivers everything a restaurant needs to open its doors, from frozen food and packaging to lightbulbs. It is the regional arm of a global supply chain group.

Files move constantly between Martin Brower systems and outside parties: partner organizations dropping files in, collecting files out, every day. In Australia and New Zealand, that entire exchange ran through SFTP and FTP servers the regional infrastructure team hosted, patched, and administered itself. Replacing them meant preserving the folder structures and connection patterns those partners already used, including an exception for one partner that required a legacy cipher.

Every External File Ran Through a Server the Team Had to Run

The servers were legacy infrastructure, and everything about them was the team's problem. Partner accounts were created by hand and permissions managed user by user. Inbound drop folders filled with files and leftover subfolders unless someone cleared them out. Company policy requires that certain countries be blocked on every platform the business uses, and on a self-hosted server, meeting that policy was engineering the team had to build and keep current on its own.

The diagnosis was simple: Martin Brower ANZ is in the business of supplying restaurants, and its infrastructure team had ended up in the business of operating file-transfer servers to make that possible.

Live Partner Connections That Could Not Break

The servers survived as long as they did because they were the live transit point for every external partner the region exchanges files with. The folder structure, the credentials, and the connection details were embedded in how those partners worked. Retiring the servers meant moving every file and the entire folder hierarchy, rebuilding permissions, re-creating dozens of accounts, and cutting outside organizations over without interrupting anyone's exchange.

And counterparties come as they are. One partner could only connect using a legacy cipher, so any replacement had to accommodate that single connection without lowering the security bar for everyone else.

That set the requirements. The replacement had to present partners with the structure they already knew, hold each partner's users in their own area, manage permissions without per-user handwork, enforce the corporate country blocklist as policy rather than as custom engineering, and run alongside the old servers until the day of the switch. Martin Brower ANZ selected Files.com to be that hosted transit point.

One Bulk Command, a Parallel Run, and a Switch

The ANZ infrastructure team ran the migration with a Files.com onboarding engineer. A single Files.com CLI command bulk-uploaded the data and full folder hierarchy from the legacy FTP server in one pass, so partners would land in a structure they already recognized. Permissions were built with Files.com Groups, with folders attached to groups rather than to individuals, so each partner's people inherited their access from the group they belonged to. The team validated the settings with sample users, then bulk-imported the remaining accounts from a CSV file.

The legacy FTP server and Files.com then ran in parallel. Additional CLI syncs picked up the files still accumulating on the server, the folder structure was locked, and password and IP restrictions were configured on the new site before anyone moved. Then came the switch: partners were pointed at a Martin Brower-branded domain through a DNS record. The one partner that needed a legacy cipher got it as a per-account setting on its own connection, while every other connection to the site runs on modern ciphers only.

No Servers to Host, Patch, or Clean Up After

With the cutover complete, the on-premise SFTP and FTP servers came out of the exchange path. Files.com is now the transit point between Martin Brower systems and outside parties, and the work the old servers demanded went with them.

• External partner organizations hold their own accounts and sign in to drop off and collect files. The ANZ team manages access at the group level, so a change to a partner's access is one edit, not a pass through every user.
• The corporate rule that certain countries be blocked on every platform is enforced by Files.com's country-based access control. It is a site setting, not something the team builds and maintains on hardware of its own.
• Inbound partner folders clean themselves up. Files.com File Expiration removes delivered files on schedule and deletes the empty subfolders they leave behind, so nobody sweeps drop folders by hand.
• There is no file-transfer server left in the region to host, patch, or keep on the network.

The change also compounds. Onboarding the next partner is configuration: a group, a folder attached to it, and accounts imported against it. Even the exceptions are configuration, because a partner that arrives running older technology gets a per-account cipher policy instead of a new piece of infrastructure.

File Exchange Without Infrastructure

Today, exchanging files with an outside party no longer means the Martin Brower ANZ infrastructure team keeping a server alive.

A team that ran file-transfer servers for a supply chain feeding more than a thousand restaurants now runs none.