New Westminster Routes Cloud Vendor Feeds Into J.D. Edwards Through Files.com 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 Ends on an Internal Network Path

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 passed through a CrushFTP server the city hosted itself in its DMZ. The IT team wanted vendor uploads over SFTP, no server of its own in the DMZ, and no inbound port into the city's network.

Retiring that server could not mean retiring the feed. Every nightly extract still had to land on the path SSIS reads, on its own, with nobody at the city carrying it. The city wanted one route: encrypted in transit, unattended end to end, and no server of its own in the middle.

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 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 system 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 the CrushFTP path 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 first vendor's nightly job was confirmed connecting and sending files roughly three weeks after the site went live.

Hundreds of Transactions a Night, Untouched by Hand

With the Files.com pipeline in production, the city's nightly ledger feeds run encrypted in transit and unattended end to end. Both daily vendor integrations now run unattended into J.D. Edwards, each extract carrying hundreds of transactions, and nobody at the city touches an extract on its way in. 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 hosts a transfer 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 around an internal file path can take modern, encrypted transfers without being rebuilt first.