A European Parking Operator Replaced RoboFTP With Files.com to Deliver Near-Real-Time Parking Data From Its Own Azure Storage

A European parking operator runs car parks across several countries. Parking is its only business: the company designs, builds, finances, and manages the facilities, many of them under concessions with the cities they sit in.

Those cities are not just landlords. Municipalities are the operator’s customers, and part of what they buy is data: near-real-time information about which car parks have space, used to guide drivers to specific routes and lots. File exchange with partners and public authorities sits underneath that business. The operator’s established exchanges ran on infrastructure it had to operate itself; with Files.com, it also built a new feed that delivers updated parking availability to municipalities in near real time.

An FTP Server at the Parking Sites, With Scripts on Both Ends

The company's partner and internal file exchange ran on its own FTP server, with a heavy layer of RoboFTP scripts moving and processing files between that server and an internal fileshare. The estate behind it was physical: on-premises HP servers, some located at the parking sites themselves, plus manual FTP processes covering whatever the scripts did not.

The cost was that every exchange depended on hardware the IT team had to keep alive and on bespoke scripts someone had to maintain. And the scripting had become load-bearing on both ends of the pipe. Replacing the server also meant finding a replacement for the client-side scripts that talked to it, work the company's Head of IT Services judged substantial enough to budget weeks just for the evaluation. That is why the estate had survived as long as it had.

Replace the Server, Keep the Azure Storage

The operator planned to move the exchange to a SaaS service, and the requirement was unusually specific. This was not a migration into a vendor's cloud. Whatever replaced the FTP server had to front-end onto the company's own Azure storage account, so that files kept landing in storage the company already owned. The replacement also had to speak the protocols partners already used and allow a gradual unwinding of the scripted estate rather than a single cutover.

The operator selected Files.com to be that front end.

Using a Files.com Remote Server Mount, the company mounted an Azure File Share onto its Files.com site. The mounted folders are windows onto the Azure storage account: a file uploaded through Files.com lands in the company's own storage in real time, and a file a partner collects is read straight from it. Partners and internal systems connect over FTP, FTPS, SFTP, or the web interface, under the operator's own domain.

The cutover was phased. The legacy FTP server ran in parallel while partners moved across, with workflows proved in a staging site before they carried production traffic.

A Continuous XML Feed, and the Cities That Collect It

The platform then became the home of a workload the old estate never carried. An application continuously uploads XML files with car park availability into dedicated folders on the Files.com site. Municipalities and transfer partners connect, collect the files, and remove them, and the data guides cars to specific routes and lots.

A folder written to that often fills relentlessly, and each file is useful for only a few hours. The company set Files.com File Expiration on the feed folders, and the pipeline now cleans up after itself.

Near-Real-Time Delivery Without a Server the Operator Runs

With the Files.com site in production, the company put the new machine-to-machine feed on a managed delivery path:

• Municipalities receive near-real-time car park availability, delivered as a continuous XML feed per group of car parks, and use it to route drivers to specific lots.
• Every file lands in the operator's own Azure storage account without an HP server or RoboFTP script chain in the delivery path.

The pattern also repeats cheaply. Bringing another group of car parks onto the feed is a folder and a service account, on a platform the company no longer has to operate.

The Server Left the Delivery Path, the Storage Never Moved

Today an application at a group of car parks writes a file, and within moments a city's system can collect it. In between there is no HP server at a parking site to keep alive, and no script chain to maintain. Files.com took over this exchange, and the files never left the operator's own Azure account. The scripted, self-hosted FTP path did not have to take the data with it when it went.