City of New Westminster Retires CrushFTP for Canadian-Hosted Files.com
The City of New Westminster is the municipal government of western Canada’s oldest city, in Metro Vancouver. It is an unusually self-reliant government. Where most British Columbia municipalities contract policing to the RCMP, New Westminster runs its own police force. It also operates its own electrical utility and fibre optic network. Roughly 1,200 employees across eight major departments run all of it.
That habit of running its own infrastructure extended to file transfer. Daily accounting feeds from cloud vendor systems flow into the city’s J.D. Edwards ERP. Engineering trades enormous drawing sets with outside contractors and consultants. Departments exchange files with developers and construction firms every week. All of it ran through a single SFTP and FTP server the city hosted itself, in its own DMZ.
The Server in the DMZ That Needed Patching Year After Year
That server ran CrushFTP, a self-hosted file transfer product with a public record of critical vulnerabilities landing year after year. For three consecutive years, a vendor advisory meant urgent, drop-everything patching of an internet-facing server that every department depended on. The city’s small IT team carried all of it: the operating system, the perimeter, the patch windows, and the exposure in between. And because the server sat in the DMZ by design, reachable from the internet so that vendors and contractors could deliver files, every one of those vulnerabilities was a live question rather than a theoretical one.
“We were using CrushFTP, and we’re fed up with all the critical security vulnerabilities that happen year after year after year.”
This was a standing condition, not a bad year. As long as the city self-hosted its transfer service, every flaw in someone else’s code was New Westminster’s emergency.
A Residency Mandate and Two Workloads on One Server
The obvious question is why a transfer server was still self-hosted at all. The answer is a hard requirement: as a municipal government, New Westminster must keep its data and servers hosted within a Canadian region. The requirement is mandatory, not aspirational, and it is why the service sat in the city’s own DMZ. In-country had been read as in-house. But Canadian residency did not require self-hosting.
The server also did two jobs at once. It was the machine endpoint for the nightly general-ledger extracts headed into J.D. Edwards, and it was the human channel for departments exchanging files with outside firms. A replacement that handled one job and not the other would have split the estate into more tools, not fewer.
So the requirements wrote themselves. The replacement had to be run by a team whose entire job is running it, so the maintenance and security overhead left the building for good. It had to keep data and servers in Canada. It had to speak SFTP and FTP, so vendor systems could reconnect without redevelopment. And it had to give non-technical staff a browser instead of an FTP client, so one platform could carry both workloads.
“We want something that’s secure and reliable, so we can sleep at night.”
The city selected Files.com to be that platform.
Two Sites in Canada, Scoped Vendor Feeds, and an Outbound-Only Agent
Files.com became the city’s single file transfer service: managed, hosted in Canada, with nothing internet-facing left inside the city’s network to defend.
Residency was answered in configuration on day one. The city provisioned separate test and production sites, both stored in Files.com’s Canadian region, AWS Canada Central, each with a geo-restriction allow-list limiting access to Canada, and both running under the city’s own domain and branding.
The machine workload moved first. Two cloud systems, Xplor for recreation management and Computrol for fuel management, push daily general-ledger CSV extracts into Files.com over SFTP and FTP, each carrying hundreds of transactions. Each vendor connects through a dedicated service account limited to its own upload folder. Inside the city’s network, a Files.com Agent lands arriving files on a network path used by J.D. Edwards. The Agent connects outbound only, so the integration required no inbound firewall rule and put no listener back in a DMZ. The city’s existing SSIS packages now read from that path instead of pulling files off an FTP server. The first vendor’s scheduled nightly feed was running about three weeks after the Files.com site was activated, and both integrations were then moved into production.
The people came second, deliberately. The city began a soft rollout in Engineering, whose consultants and contractors exchange CAD and PDF drawing sets as large as 50 GB. Those now move through password-protected Files.com share links with expiration dates, and staff work entirely in the browser, with nothing to install on either end. Two Engineering staff hold group and folder admin rights over their own project folders, adding users and granting access themselves rather than routing every request through IT. The exchange is transient by design: a 30-day default expiration clears what arrives, and anything that constitutes an official city record is filed into the city’s OpenText records system, which remains the system of record.
Unattended Daily Feeds and Nothing Left to Patch
With Files.com in production, New Westminster replaced a server it had to defend with a service it only has to use.
- The two daily vendor feeds run unattended into J.D. Edwards, with nobody moving files between systems by hand.
- The mandatory residency requirement is met without self-hosting: both sites live in AWS Canada Central behind a Canada-only allow-list.
- A vendor’s critical advisory is no longer the city’s emergency, because there is no internet-facing transfer server in the DMZ left to patch.
- Machine and human workloads share one governed platform: the same site that feeds the ERP carries 50 GB drawing sets between Engineering and its contractors, while Engineering staff administer access to their own project folders.
The pattern also repeats cheaply. The next vendor system that needs to deliver files to the city is a scoped service account and an upload folder, landing on the same internal path through the same Agent, with no new infrastructure and no new firewall conversation.
Residency Without Self-Hosting
The lesson in the city’s move is about the mandate itself. The requirement that data and servers stay in Canada says where the data must live. It never said the city had to patch the server. New Westminster kept every byte in Canada and got out of the business of defending internet-facing infrastructure.
Related Customer Stories
Government & Education
The College Board Retired Its In-House SFTP Server to Deliver PowerFAIDS Releases Through Files.com
The branded portal had to absorb release-day surges, enforce subscription entitlements, and secure database uploads containing student and parent PII.
Read story →
Government & Education
City of Albuquerque Uses Files.com to Deliver 15 GB Body-Camera Footage Without Relaxing Its Email Lockdown
A centrally managed Files.com site gave employees and outside parties a secure path around email’s file-size and file-type limits.
Read story →

Government & Education
City of Midland Retired SolarWinds Serv-U After a One-Day Migration and Is Phasing Out Mapped Drives
Files.com preserved all 46 Serv-U users’ credentials while letting each department leave its legacy file share on its own schedule.
Read story →