A Wind Turbine Manufacturer Moves From Microsoft IIS FTP to Files.com Without Moving Data Out of Azure

A global wind turbine manufacturer designs, manufactures, installs, and services turbines for utilities, industrial customers, and governments worldwide. A global IT services firm manages IT infrastructure on the manufacturer’s behalf.

An operation that size trades files with the outside world constantly. Banks and vendors send files in and take files out, and project teams share files with external counterparties at different levels of access. For years, that external exchange ran through on-premises FTP and SFTP servers.

Replacing it was not a lift-and-shift. Data at rest had to remain inside the manufacturer’s own Azure tenancy. The service needed a company-named domain on dedicated IP addresses rather than a vendor’s broad public range. Every user had to come from Entra ID, with multi-factor authentication enforced there and no locally created accounts. Administration also had to be delegable to the teams that owned each project.

Identity, Administration, and Data Residency as Design Requirements

The Microsoft IIS server provided FTP alongside a web interface, while an on-premises SFTP server received files from banks and other vendors. Both authenticated users with accounts created on the server itself, and neither could take its users from Entra ID.

The manufacturer’s standard for the replacement was that every user authenticate through Entra ID, with a second factor enforced there and no accounts created locally. The existing servers could not meet that standard, because local identity was how they were built.

Administration was the second requirement. On the existing servers every partner connection was configured and tested by hand, and every access change flowed through central IT. The manufacturer wanted the project owners who know who needs access to be the ones who grant it.

As the organisation moved off on-premises infrastructure into Azure, the manufacturer set out to move external exchange with it, onto a platform that met every line of that mandate.

Working with its IT services provider, the manufacturer selected Files.com to provide the governed front door.

A Files.com Front Door on Storage the Manufacturer Already Owns

Files.com became an exchange layer with no data of its own. Using a Files.com Remote Server Mount, the company’s Azure Files share sits behind the platform, so every file a bank or vendor sends over SFTP lands directly in the manufacturer’s Azure tenancy and stays there. The Azure storage account’s firewall is restricted to Files.com addresses, and the design uses no on-premises server or agent.

Identity moved entirely to the directory. Users sign in through Entra ID over SAML, while SCIM provisions and deactivates their Files.com accounts as the directory changes. Those accounts are directory-managed rather than created locally. Multi-factor authentication is enforced through Entra, and folder permissions follow directory groups mirrored in Files.com.

Each external counterparty gets its own folder, with access granted only to that vendor’s named users and SSH key pairs generated on the platform for their connections. The site runs on a company-named subdomain pointed at dedicated public IP addresses, with certificates managed automatically.

Because the IT services provider delivers the service, it administers a Files.com parent site while the manufacturer operates on its own child site. This keeps the integrator’s administration separate from the client’s day-to-day environment.

Implementation covered the custom domain, Azure Files connectivity, and identity integration. From site activation to completed onboarding took roughly eight weeks, across change-approval processes spanning the company’s Azure, Entra ID, and network teams, the services provider, and the manufacturer’s engineering contacts.

Test folders and groups were built in Files.com while the existing servers remained in place, and partner SFTP connections were then scheduled to move in batches.

A Repeatable Operating Model for External Access

On Files.com there is no local user administration. Accounts and group membership follow Entra ID, and every login carries the second factor cybersecurity requires. When someone leaves, access ends where the directory says it does.

Routine access changes no longer route through central IT. Group administrators manage the users in their own groups, so the project owners who know who needs access are the ones who grant it.

Onboarding the next counterparty is also repeatable rather than bespoke: a folder, a permission set, and an SSH key, designed for a partner estate expected to span dozens of SFTP connections.

The Mandate Met Without Moving the Data

Before, an access change was a request to a central IT team, executed by hand. Now the group administrator who owns a project grants it, the directory decides who can log in at all, and the file a bank sends lands in Azure storage the manufacturer already owned.

Files.com gave the company a way to satisfy every line of its security mandate: no local accounts, a second factor on every login, data at rest in its own cloud, and a named domain on dedicated addresses. None of it required rebuilding the exchange or relocating a byte of data. It required putting something governable in front of storage the company already had.