Interparking Replaced RoboFTP With Files.com to Deliver Minute-by-Minute Parking Data From Its Own Azure Storage

Interparking has been building and running car parks since it designed Parking 58 for the 1958 Brussels World Expo. It now operates more than a thousand parking facilities across nine European countries, and more than 117 million motorists use its services each year. 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 Interparking 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. Interparking’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 every minute.

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

Interparking'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 Interparking'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

Interparking 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 Interparking'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.

Interparking selected Files.com to be that front end.

Using a Files.com Remote Server Mount, Interparking 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 Interparking'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 Interparking'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.

An XML File Every Minute, and the Cities That Collect It

The platform then became the home of a workload the old estate never carried. An application uploads an XML file with car park availability every minute 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 every minute fills relentlessly; within months, thousands of files had accumulated, each useful for only a few hours. Interparking set Files.com File Expiration on the feed folders to 24 hours, and the pipeline now cleans up after itself.

Near-Real-Time Delivery Without an Interparking-Operated Server

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

• Municipalities receive near-real-time car park availability, delivered as one XML file per minute per group of car parks, and use it to route drivers to specific lots.
• Every file lands in Interparking'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 Interparking 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 the minute 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 Interparking's own Azure account. The scripted, self-hosted FTP path did not have to take the data with it when it went.