Choosing between iPaaS, ETL and custom scripts for local government
Three common ways to connect city systems, what each is good at, and the questions that matter for a public agency: data retention, staff skills, and who fixes it at 2 am.
When two city systems need to talk, there are three usual answers: a general-purpose integration platform (iPaaS), an ETL tool, or a custom script. Each is a reasonable choice somewhere. The trick is matching the tool to the job and to the agency.
This guide describes the categories, not specific products. Products within a category vary a lot, so use these as questions to ask, not verdicts.
The three categories
General-purpose iPaaS
Integration platforms built for any business. They connect cloud apps, usually with live, event-driven flows: when something happens in one app, do something in another.
- Good at: app-to-app flows, webhooks, large connector libraries for common business software.
- Watch for: pricing and licensing built for large enterprises; connectors aimed at commercial software rather than permitting, 311 or clerk systems; whether the platform stores payloads in logs or queues.
ETL tools
Extract, transform, load. Built to move large volumes of data on a schedule, usually into a warehouse or reporting database.
- Good at: bulk loads, nightly syncs, reshaping data for reporting.
- Watch for: staging tables that keep a full copy of the data; tools aimed at data engineers rather than city staff; weaker support for record-by-record, near-real-time work.
Custom scripts
A developer writes code that calls one system and writes to another, often run by a scheduled task on a server.
- Good at: exactly the job it was written for; no license cost.
- Watch for: the person who wrote it leaving; no run history; no alerts; credentials in a config file; every change needing a developer.
Questions that matter for a public agency
Generic buying guides ask about connector counts and throughput. For a city, county or district, these questions usually matter more.
Does it keep a copy of our data?
Any copy of resident data is something you have to secure, retain under your schedule, and potentially produce in a public-records request. Ask where records go during a run: memory only, or logs, queues and staging tables? What does run history keep?
Does it know our systems?
A connector for a CRM doesn't help if your work runs through Accela, OpenGov, Laserfiche, Cityworks or a 311 system. Ask which government systems are pre-built, and what happens for the ones that aren't. Can it import an OpenAPI file, or does each new API need custom work?
Who builds and changes flows?
If only a developer can change a flow, every new field is a ticket. Ask whether an analyst or IT generalist can build one, and whether they can see the actual data at each step before going live.
Where can it run?
Some agencies need integrations on their own servers, sometimes on networks with no internet access. Ask whether the product can be self-hosted, and whether it depends on outside services or content networks to work.
What happens when it fails?
At 2 am, the bank file has a bad row. Ask how failures are reported, whether one bad record stops the whole run, and whether failed records can be replayed without re-running everything.
Can we prove what happened?
Auditors and records requests ask "where did this record go?". Ask whether you can search a record ID and see every run it went through, and who changed a flow and when.
A rough fit guide
- One simple, stable connection, with a developer on staff: a script may be fine. Add logging and alerts.
- Many commercial cloud apps, live events, enterprise budget: a general-purpose iPaaS is built for this.
- Large nightly loads into a reporting warehouse: ETL is built for this.
- Many government systems, a mix of live and scheduled flows, files and databases, small IT team, strict data rules: look for something built for local government.
Where SentraBridge sits
SentraBridge was built for that last row. It handles both live flows (webhooks, database change triggers) and scheduled ones, with pre-built connectors for government systems plus any REST/JSON API, databases, GIS and SFTP.
It's pass-through: records are held in memory during a run and never stored, and run history keeps counts, timings and IDs only. It runs hosted by Computer Systems Plus or on your own servers. See the comparison page for a side-by-side by category.