City of Las Vegas Retires Working PowerShell Transfer Scripts With Files.com—Without a Big-Bang Cutover

The City of Las Vegas is the municipal government of Nevada's largest city, serving more than 640,000 residents. It is a broader operation than most city halls. Alongside planning, licensing, and parks, the city runs its own municipal court, its own detention center, a marshals unit that polices city property, and Las Vegas Fire & Rescue, the second-largest fire department in Nevada.

Each of those functions exchanges data with organizations outside city government: credit bureaus, collections vendors, and processing partners that take city files and send results back. For more than a decade, much of that outbound exchange ran the same way every time. A PowerShell script on a Windows scheduled task pushed files from a city server to each external destination.

A Script for Every Counterparty

Each automated external destination had its own script and its own scheduled task, written and maintained by the city's systems administrators, with manual WinSCP transfers covering the exchanges that never got a script. The scripts themselves were dependable. The pattern around them was not.

A scheduled task lives on one server, and it only fires if that server is up when the clock hits. Reboot at the wrong moment and the job is silently skipped, which means a data feed a counterparty expects on schedule silently does not arrive. Every script was also standing maintenance owned by the team that wrote it. And every new counterparty meant another one: another connection to build by hand, test, schedule, and keep working.

The diagnosis was never any single script. It was the estate. Each new external data relationship the city took on made the library of scripts larger, more fragile at reboot time, and more expensive for the systems team to own.

Working Scripts Are the Hardest to Replace

The scripts were working, which is exactly why the pattern lasted. The PowerShell workflows had run reliably for more than ten years. A record like that cannot justify a rip-and-replace, and the files moving through these connections are the kind a counterparty notices when they are late. A big-bang cutover risks exactly the missed run the whole apparatus exists to prevent.

The systems team had been looking for a way off the pattern since at least 2021, when it first asked whether folders on internal servers could reach the platform without a script or a scheduled task behind them. As the number of counterparties grew, the requirements settled into three. Recurring sends had to run without depending on a single Windows server being up. Connections had to be managed by the platform rather than maintained as code. And the migration path had to let each workload prove itself alongside its existing script, connection by connection, with nothing cut over on faith.

The City of Las Vegas selected Files.com to run those managed connections.

An Agent Inside the Network, Managed Connections Outside It

The city built the replacement in two halves. Inside its network, the Files.com On-Premise Agent connects internal servers to the platform, so files generated on a city server move into Files.com without a script pushing them. Outside it, remote server connections managed on Files.com hold the endpoint details and schedules for each counterparty, and the platform runs the deliveries itself.

The city's feed to one of the national credit bureaus shows the full pattern. Files land in a drop folder on Files.com. A Files.com Automation stages each file into a send folder. A daily sync over the platform's remote server connection delivers the staged files to the bureau's SFTP server, and an email confirmation closes the loop on every run. No city server has to be up at the right moment, and no scheduled task has to fire. A second recurring partner feed runs the same pattern every 15 minutes.

The migration itself follows one rule: nothing retires until its replacement has earned it. Each PowerShell job stays live while the managed connection runs beside it in production. Once the Files.com version has proven itself, the script retires, and each connection moves on its own schedule.

The Next Counterparty Is a Connection, Not a Script

With the managed connections in production, the city replaced hand-owned scheduled jobs with deliveries the platform runs and confirms.

• The credit bureau feed runs in production on Files.com and is working well, with no script behind it and no scheduled task to fire.
• A whole failure mode is gone from migrated workloads. A delivery no longer depends on one Windows server being up at the right moment, and every run ends with a confirmation instead of an assumption.
• Maintenance moved off the team. A managed connection is configuration that Files.com operates, not code a systems administrator has to keep working.
• Onboarding the next counterparty is configuration rather than development: a connection, a schedule, and a parallel run against the old script, instead of new code to write, test, and own indefinitely.

The last of those is the one that compounds. The credit bureau workflow was the first proof, and the city can now apply the same pattern as it moves the rest of the estate.

Retiring Working Automation Without a Cutover

What has changed is what a new external data relationship costs the city. It used to mean another script written, tested, scheduled, and owned by the systems team, with a failure mode nobody saw until a feed did not arrive. Today it means a connection configured on Files.com, delivered on the platform's schedule, and confirmed on every run. A decade of working scripts did not have to be ripped out in a weekend. It is being replaced by managed connections without another script for the systems team to maintain, one connection at a time.