Domain
SDWIS/State and DW-SFTIES
The systems a drinking water primacy agency runs to track its public water systems, sampling and monitoring, compliance determinations, and reporting to EPA. The schemas are federal, the deadlines are statutory, and the numbers have to reconcile. The firm takes defined pieces of that work — migration, mapping, interfaces, reporting, reconciliation — against the systems an agency already has.
What DW-SFTIES actually changes
DW-SFTIES — the Drinking Water State-Federal-Tribal Information Exchange System — is EPA's replacement for SDWIS/State, and the change is structural rather than cosmetic. SDWIS/State is a database the agency runs on its own server and can query directly. DW-SFTIES is centrally hosted, organized as a set of independent services with published OpenAPI contracts, and reached over an authenticated connection through EPA's Central Data Exchange.
The practical consequence is easy to state and expensive to discover late: the local database goes away. Every report, portal, extract, scheduled job, and spreadsheet macro that reads SDWIS/State tables directly loses its data source, and has to be re-pointed at an API with a different shape, a different vocabulary, and a token on every request.
EPA publishes the crosswalk between the two, and it is worth reading before anyone promises a clean cutover. Several hundred tables map across; a residue does not map at all. Those unmapped columns are where an agency's history lives — the local codes, the fields somebody added in 2004, the values the rule managers rely on that were never part of the federal model. Finding them is a data problem with a definite answer, and it is much cheaper to answer before migration than during it.
Where the federal program ends
EPA funds real transition support, and an agency should use all of it. That support is aimed at the agency's transition plan, its data quality, and moving its SDWIS/State data into the new system. It is not aimed at the twenty-odd applications the agency built around SDWIS over two decades. Those belong to the agency, and re-pointing them is ordinary engineering work — which is the work this firm takes.
Writing against the new contract before you can reach it
The usual sequencing problem with a transition like this one is that the applications cannot be rewritten until the new system is reachable, and the new system is not reachable until the agency is far along in its transition. That ordering pushes all of the application work into the window where it is most disruptive.
It does not have to hold. The federal API contract is published, so it is possible to stand up a translation layer that serves DW-SFTIES-shaped responses out of the agency's existing SDWIS/State database — the new interface, the old data, no change to the system of record. Applications get rewritten against the federal contract while the current system is still running normally, and repointing them at EPA later becomes a configuration change rather than a rewrite.
The firm has built exactly this, against EPA's published specifications, running on SQL Server, Oracle, or PostgreSQL. Its responses are checked against the federal OpenAPI documents by an automated conformance suite, and a separate tool diffs the live specification against the pinned copy so that a federal schema change surfaces as a failing test rather than as a surprise. It is open source, and any agency is free to run it, read it, or change it.
Where we work
- SDWIS/State
- The data model as it is actually populated after decades of use — monitoring and sample schedules, compliance determination, inventory extraction, and the local conventions that never made it into any document.
- DW-SFTIES transition
- Reconciling the current inventory against the federal schema, identifying what will not map cleanly before it becomes a migration failure, and building against the new API contract while the existing system stays in service.
- Interfacing applications
- The applications built around SDWIS over the years — moving them off direct database access and onto the federal API, one at a time, without taking the program offline.
- EPA data exchange
- Federal reporting, submission through CDX and the Exchange Network, and mapping legacy fields onto current federal schemas.
- Staff and public portals
- Sample scheduling, laboratory result submission, monthly operating reports, inspections and sanitary surveys, lead service line inventory, operator certification tracking, Consumer Confidence Reports, and public information requests.
- Compliance analysis
- Capacity assessment reporting, monitoring and violation analysis, source water assessment data, and operational dashboards.
- Platform migration
- Moving regulatory databases between platforms — including onto PostgreSQL, which is what the federal system runs on — with the SQL dialect differences and the date encodings that predate the current schema handled explicitly. Staged, with parallel operation and reconciliation against the system of record while the program keeps running.
Why this work is its own discipline
A drinking water program is not a generic CRUD application with reports bolted on. The determination logic is written in federal rule, the reporting window is fixed by statute, and an error does not surface as a bug report — it surfaces as a finding.
The data is also old. State inventories carry decades of history through multiple platform migrations, and the edge cases that break a naive rewrite are the ones nobody documented. Knowing where those are is most of the job.
Scoped to a task, not a platform
The firm takes defined pieces of work against the systems an agency already runs. That is the usual engagement: a migration or mapping job, a reconciliation, an interface, a reporting or extraction task, a schema change that has been deferred because nobody wants to touch it. It does not require adopting a platform, and it works alongside whatever software and vendors are already in place.
The transition is the clearest current example. It is a defined problem with a defined end state — reconcile the inventory, find what will not map before it becomes a migration failure, move the data, move the applications, and verify the result against the system of record. That is a contract with edges, which is a better first engagement for both sides than an open-ended one.
Built on open technology, and the agency keeps it
The work is written on open technology and delivered to the agency: the source, the data model, and the reasoning behind both. It runs where the agency decides it runs — in the state data center, in the agency's own cloud account, or somewhere else — and the regulatory database stays under the agency's control rather than inside a vendor's tenant. There is no per-seat cost that grows with the program, and no part of it stops working because a business relationship ends.
That matters here more than in most places. A drinking water program has to be auditable by people who did not build it, and it has to still be running in fifteen years. Work that can be read, moved, and continued by agency staff or by another contractor is the version that survives that long.
Regulations and systems
Talk about a piece of work
If you run a primacy agency program, a laboratory interface, or a utility reporting obligation, we would welcome a conversation about how the firm works.
- Phone
- (888) 288-4775