MS4 software vs ArcGIS: why most municipal programs need both

The question municipal GIS staff ask most often when a stormwater coordinator brings in a compliance software demo is some version of this: we already have ArcGIS, why do we need this too? The honest answer is that the two tools do different jobs. They overlap on a map, but they are not interchangeable, and most working MS4 programs end up using both.

This post is about what ArcGIS does well in municipal stormwater, what it is not designed to do, what purpose-built MS4 software adds, and how the two coexist in practice without one trying to replace the other.

The two-tools question

The misconception that drives most of the confusion: that compliance software is a competitor to ArcGIS. It is usually not. ArcGIS is a GIS platform. Compliance software is a workflow product that happens to need spatial context. The features overlap on the map view, where both tools show outfalls, BMPs, and sites with status indicators. The features stop overlapping the moment you open one of those features and start documenting a year of inspection history.

A useful way to frame the question: GIS is for the spatial state of the system. Compliance software is for the temporal record of program work against that system. The map and the records are related, but they are not the same thing.

What ArcGIS does well in municipal stormwater

ArcGIS Online, ArcGIS Enterprise, and the broader Esri stack are doing serious work in most municipal stormwater programs already. The strengths are real:

Authoritative spatial data. GIS staff maintain the city’s official storm drain network, parcel boundaries, watershed delineations, and basemap layers. Every other system in the agency reads from those layers. That is the right place for that data to live.
Hydraulic and hydrologic modeling integrations. When the city does drainage capacity studies, watershed analyses, or flood modeling, the GIS layers feed the modeling tools. ArcGIS Pro and the related extensions handle that better than any compliance product.
Cross-departmental publishing. GIS Online lets the city publish public-facing maps for residents (storm drain locations, public BMPs, watersheds). That is a GIS function, not a compliance function.
CAD and engineering integration. As-built drawings from new development land in CAD systems and get translated into GIS layers. The bridge between engineering and operations runs through GIS.
Custom analysis. A GIS analyst running spatial analytics on the storm drain network, identifying gaps in coverage, modeling pollutant load reductions, doing watershed-based prioritization, is using ArcGIS for what it was built for.

A program that has invested in ArcGIS, has a GIS analyst on staff, and has its authoritative spatial data well-maintained is in a strong position. The compliance question is not whether to keep that. It is what to add for the work ArcGIS is not designed to do.

What ArcGIS is not designed to do

ArcGIS is a GIS platform. It is not a compliance workflow product. The places where municipal stormwater programs run into trouble using ArcGIS as their primary compliance tool tend to follow consistent patterns:

Permit-aligned reporting. The annual MS4 report is structured around the six Minimum Control Measures and rolls up counts of inspections, IDDE incidents, BMPs, training events, and enforcement actions across the reporting year. ArcGIS can store the underlying data. It is not built to assemble the report from that data automatically. Programs using ArcGIS for compliance end up reconciling spreadsheets to GIS attribute tables every March, which is the same problem the spreadsheet stack has, with extra steps.

Field workflow that survives no signal. Mobile inspections in the field need offline capture, structured forms, photo and GPS attachment, and immediate availability when connectivity returns. Esri’s Field Maps and Survey123 do parts of this, but configuring them for the full inspection workflow (deficient findings, follow-up scheduling, escalation to enforcement, sign-off, audit log) typically requires a meaningful amount of GIS staff time and ongoing maintenance.

IDDE investigation continuity. An IDDE investigation can span weeks, multiple visits, multiple inspectors, and multiple agencies. Keeping the chronology on a single thread, with every screening visit, photo, sample, and source-tracing step linked to the original incident, is a workflow problem more than a spatial problem. ArcGIS is not designed around that kind of multi-step temporal record. Detailed in the IDDE complaint-to-closure playbook.

Audit-defensible record history. When a state-agency reviewer asks “what changed on this BMP record on November 14, 2024, and who changed it,” the answer is supposed to be on screen. Most ArcGIS deployments do not maintain that level of attribute-level audit log out of the box. Adding it is possible, but it is custom configuration that has to be maintained.

Cadence-aware overdue tracking. ArcGIS does not natively know that catch basin 04CB17 is twenty days overdue for its annual inspection. That logic has to be built. Most programs that build it in ArcGIS end up with a custom workflow that one staff person maintains, and that staff person becomes the system.

Cross-cutting program views. The annual report’s MCM 5 section needs every BMP inspection across the program for the year. The IDDE log needs every incident across the program. The training records need every staff training across the program. ArcGIS is good at spatial views and at attribute queries on a layer. It is less native at cross-cutting program views that span multiple feature classes and time windows.

None of these are reasons to abandon ArcGIS. They are reasons not to expect ArcGIS to be the compliance system on its own.

What purpose-built MS4 software adds

A compliance product designed around the six MCMs and the annual reporting cycle adds the workflow pieces that ArcGIS does not natively cover:

Permit-aligned reporting. The annual report assembles automatically from the inspection, IDDE, BMP, and enforcement records logged through the year. Counts are derived from records, not typed in. Manual overrides leave a one-line audit-log entry.
Mobile inspection workflow. Structured, permit-aligned forms with offline capture, GPS, and photo attachment. The inspector in the truck files the inspection through the same interface that took the photo. Detailed in the photo and GPS evidence guide.
IDDE thread continuity. Complaint intake, screening visits, source tracing, enforcement, and closure on one record per incident. Photos and field readings attach to the original thread.
Cadence tracking per asset. The system knows which inspections are overdue and which are coming due, by program and by structure. Drift gets flagged before it becomes an audit finding.
Audit log on every record. Create, edit, and override events are timestamped and attributed. The “what changed and why” answer is on screen.
Cross-program views. A single readiness rollup across all six MCMs. A single annual report view that spans the program. A single enforcement view that spans years.

The differentiator is permit alignment. The product is structured around the program the city actually runs, not around the underlying spatial data.

How the two work together in practice

Municipal stormwater programs running ArcGIS plus purpose-built MS4 software typically organize the boundary between them like this:

ArcGIS owns the authoritative spatial data. Storm drain network, parcel boundaries, watershed layers, basemaps, hydraulic models, public-facing maps. GIS staff maintain these layers as part of the city’s broader GIS operation.

MS4 software owns the program workflow. Inspections, IDDE incidents, BMP inspection history, enforcement records, training logs, annual reporting. Stormwater staff maintain these records as part of the compliance program.

The boundary is the spatial reference. When the MS4 software needs a site, an outfall, or a BMP, it imports from the GIS layer. When the GIS team needs to know inspection history on a structure, the structure’s record in the MS4 software is one click from the map. Coordinates flow in and out of both systems in standard formats (GeoJSON, shapefile, CSV with latitude and longitude). Neither system is the source of truth for the other system’s data.

This boundary is the operational pattern that holds up. ArcGIS staff maintain what they are good at maintaining. Stormwater staff maintain what they are responsible for. Neither team is forced to learn the other’s tool, and neither tool is being asked to do something it was not built to do.

Common patterns and anti-patterns

Pattern that works: Stormwater software imports outfall and BMP layers from ArcGIS. Field inspectors capture inspections in the stormwater software. The annual report rolls up from the stormwater software. The GIS team can pull a current “all inspected BMPs” export back into ArcGIS for spatial analysis when needed.

Pattern that works: Stormwater software is the system of record for compliance work. ArcGIS is the system of record for spatial data. When a new BMP is built, it lands in ArcGIS first, then gets imported into the stormwater software’s BMP inventory. When a BMP is decommissioned, the change happens in ArcGIS, and the stormwater software inventory updates on the next sync.

Anti-pattern: Trying to do permit-aligned reporting in ArcGIS by building custom workflows on top of the standard layers. This works for a year, then drifts as permit requirements update or staff turnover changes who maintains the custom configuration.

Anti-pattern: Trying to do authoritative spatial data management in compliance software. The compliance software is reading the city’s spatial data, not owning it. If the compliance software starts being the source of truth for the storm drain network, the city ends up with two competing authoritative sources, and they will diverge.

Anti-pattern: Treating the two tools as competitors and forcing a choice. The choice is rarely necessary. The cost of running both, when the boundary is clean, is much lower than the cost of forcing one tool to do the other tool’s job badly.

Honest scope: what we do and don’t claim about GIS

NPDESTracker is GIS-aware compliance software. It is not a GIS platform. The product imports and exports standard GIS file formats (GeoJSON, shapefile, CSV with latitude and longitude) so it can coexist with ArcGIS Online, ArcGIS Enterprise, or QGIS. The product does not claim to replace any of those.

We do not have a partnership with Esri. The interoperability story is built on open file formats and standard coordinate systems, which is what most municipal GIS workflows actually run on day to day. The full GIS workspace story, including what the product is and what it deliberately is not, is on the GIS workspace page.

For Phase II programs that already use ArcGIS, the practical evaluation is whether the compliance workflow gaps (reporting, mobile capture, IDDE continuity, cadence tracking, audit log) are worth the cost of adding a second tool. For programs without ArcGIS, the question is different and probably involves whether a GIS investment is worth making at the same time.

The easiest way to see how the boundary actually works is the interactive demo. Open the GIS workspace alongside the inspection workflow and see how the two cross-reference. Sample data, browse only, no signup.