ENGIE ANZ Retires Cerberus FTP Without Giving Locked-Down Servers Internet Access

ENGIE Australia & New Zealand is the ANZ arm of the ENGIE global energy group. The business spans energy generation and retail, while its trading arm operates as the ANZ entity of GEMS, ENGIE's global energy management and sales business.

With the Files.com workflow in production, ENGIE ANZ retired Cerberus FTP and completed a cloud migration that its own network policy had appeared to rule out.

The trading business runs on generation meter data. Files carrying that data have to move between power stations, external market counterparties, and backend trading systems continuously, machine to machine, all day. One workflow carries a contractual obligation to complete a file pickup or dropoff once every 8 to 10 seconds.

The servers that do that backend processing sit on a network built to say no. Corporate policy bars them from all inbound access and from all outbound external access. A trading operation that lives on continuous external data exchange, running on servers forbidden to touch the internet, was always going to make file transfer the hard part of any move to the cloud.

The On-Premises Exchange Point That Had to Go

For years, the exchange point was a Cerberus FTP server running on-premises. External counterparties delivering data to the trading business each held an individual SFTP account on it. The high-turnover workload, the one on the 8-to-10-second clock, was held together with standard Windows functionality: UNC paths and file copies between servers that all shared the same network.

That arrangement works for exactly as long as everything stays on one network. ENGIE ANZ was required to move off the on-premises solution, and the moment the destination became the cloud, every piece of the arrangement stopped being viable at once. A contractual obligation measured in seconds was riding on ordinary Windows file sharing, and the trading business's external exchange depended on a single server that the organisation was committed to retiring.

No Way In, No Way Out, and a Clock That Never Stops

The reason the migration could not simply proceed was the network policy. Any cloud service is, by definition, external. Pointing the backend servers at a cloud endpoint was forbidden twice over: they could not accept an inbound connection, and they could not make an outbound one. The only permitted path out of the estate was the company's Automate orchestration service, which could connect outbound on the servers' behalf. The architecture could not be lifted to the cloud. It had to be rethought around a single outbound-only egress path.

The second constraint was the clock. This was not a nightly batch that could tolerate a slow link. Whatever replaced the on-premises server had to sustain a file movement once every 8 to 10 seconds under contract.

Together, those constraints defined what the replacement had to be: a fixed exchange point in the cloud that external counterparties could reach inbound over the SFTP they already used, that the sealed estate could reach outbound-only through Automate, that kept each counterparty's access separate from the others, and that could sustain the contractual rate. ENGIE ANZ selected Files.com to be that exchange point.

A Rendezvous Both Sides Could Reach on Their Own Terms

Files.com became the meeting point between two networks that could not talk to each other directly. Neither side changed its posture; both sides reach Files.com on the terms their own rules allow.

Each external counterparty kept SFTP access through an individual SSH-key-authenticated Files.com account, with meter data organised into a dedicated folder for each power station. Automate Enterprise remains the sole permitted egress path, connecting outbound to Files.com to pick up and drop off files on behalf of the backend servers, which never gain any external access.

Sustaining the rate took testing rather than assumption. Running the Files.com CLI in both directions introduced significant delays, so the team settled on SFTP for uploads and the CLI for downloads, a combination that met the contractual cadence.

The Server Is Gone and the Network Policy Never Moved

The contractual workflow now sustains its once-every-8-to-10-second movement rate against Files.com. External counterparties continue to deliver over SFTP through separate accounts, while the backend servers exchange generation meter data without gaining inbound or outbound external access.

The pattern also extends without a network change or a new server: another counterparty is another SFTP account and key, and another generation asset is another folder.

A Cloud Migration That Asked Nothing of the Firewall

Moving file exchange to the cloud looked like it required giving locked-down servers a path to the internet. It required the opposite: a point in the cloud that both sides could already reach on the terms their own networks allow. The lockdown and the migration were never in conflict, and even a workflow on an 8-to-10-second contractual clock fit through an outbound-only connection.