New Westminster Moves J.D. Edwards Feeds Off CrushFTP Without Rewriting SSIS

The City of New Westminster is the municipal government of western Canada's oldest city, serving close to 90,000 residents in the Metro Vancouver region of British Columbia. Around 1,200 employees deliver services spanning policing, parks and recreation, a city vehicle fleet, and the oldest municipal electric utility in Western Canada.

Operations that broad run on many systems, and increasingly those systems live in vendors' clouds. Recreation registration runs in Xplor. Fleet fueling is tracked in Computrol. But the general ledger every one of those transactions settles into is J.D. Edwards, an ERP running on servers inside the city's own network. Every day, financial data has to cross from vendors' clouds into that network, as files.

A Nightly Ledger Feed That Was Either Unencrypted or Manual

Each night, Xplor and Computrol export a general-ledger extract, a CSV carrying hundreds of transactions. On the receiving end, SSIS packages on the J.D. Edwards servers transform each file and load it into the ERP. Those packages were built years ago, and they consume files from an internal network path. SSIS does not speak SFTP. The city needed to change the route without rewriting the packages.

That one limitation dictated the whole pipeline. For the extracts to reach a path SSIS could read, they traveled over plain FTP, through a CrushFTP server the city hosted itself in its DMZ. The IT team wanted off FTP altogether: an unencrypted protocol carrying financial data, running on a self-hosted product that had required urgent patching against critical vulnerabilities in three consecutive years.

When the city finally shut that server down rather than keep maintaining it, the pipeline's other mode appeared. With no FTP endpoint, the daily feeds fell to the people who own the systems. They retrieved each extract by hand, transformed it, and pushed it into J.D. Edwards, spending hours every week on transfers that used to run themselves just to keep the ledger current. The city's financial pipeline could be insecure or it could be manual. It had no third mode.

The Fix Could Not Touch SSIS

The obvious modernization, moving the vendor feeds to SFTP, was blocked at the far end. SSIS cannot retrieve files over SFTP, and rebuilding the J.D. Edwards integrations around a different transfer method was exactly the project the team did not want. The packages worked, the ERP depended on them, and the problem was never the ETL logic. The problem was how files got to it.

So the requirement took a specific shape. Something had to accept nightly pushes from cloud vendors over the transfer protocols their systems already speak, then land each file on the internal network path SSIS already reads, without opening an inbound port into the city's network. And because this is a municipal government, the data had to stay hosted in Canada.

The City of New Westminster selected Files.com to be that bridge.

A Scoped Account for Each Vendor, an Agent Inside the Network

Files.com became the handoff layer between the vendors' clouds and the on-premise ERP, and its job splits cleanly in two: govern what comes in, and deliver it inside.

On the intake side, each vendor received a dedicated service account on the city's Files.com site, with read, write, and list permissions scoped to its own upload folder and nothing else. Xplor's and Computrol's scheduled nightly jobs point at the Files.com endpoint and push their extracts the same way they pushed them before, just to a different host.

On the delivery side, the city deployed the Files.com Agent as a Windows service on a virtual machine inside its network. The Agent connects outbound to Files.com and nothing connects in, so the city opened no inbound firewall port and put no new server in its DMZ. Through a Remote Server Mount, the Agent writes each vendor upload to a UNC path on the J.D. Edwards server network. The SSIS jobs were retargeted from FTP retrieval to that mount. The packages themselves were not changed.

The city built all of it to its own standards: separate test and production Files.com sites, each with its own Agent on its own VM, matching the test and production separation the city applies to every system. Both sites run in AWS's Canada Central region with access restricted to Canada, satisfying the requirement that municipal data stay in the country. The site went live in June 2025, and the first vendor's nightly job was confirmed connecting and sending files roughly three weeks later.

Hundreds of Transactions a Night, Untouched by Hand

With the Files.com pipeline in production, the city replaced a feed that was either unencrypted or manual with one that is neither. Both daily vendor integrations now run unattended into J.D. Edwards, each extract carrying hundreds of transactions, and the system owners who had been importing those files by hand every day no longer touch them. Not one SSIS package was rewritten; only the way files arrive changed.

The pattern also compounds. The next cloud system that needs to reach J.D. Edwards is a service account scoped to its own upload folder, because the Agent, the mount, and the path to SSIS are already in place. What was built for two feeds is now the standard route for every feed after them.

The Legacy Integration Never Had to Move

Today a ledger extract leaves a vendor's cloud in the evening and is sitting on the path SSIS reads before anyone at City Hall is at a desk. The staff who own the recreation and fuel systems spend their week running those systems, not carrying their files, and nobody at the city defends an FTP server to make that true.

What New Westminster's experience shows is narrower and more useful than a modernization story: the legacy system never had to move. SSIS still cannot speak SFTP, and it no longer matters, because Files.com carried the modern transfer to the exact spot the old tooling already reads. An ETL estate built in the FTP era can get off FTP without being rebuilt first.