The systems that run permits, inspections, benefits, and cases were built to last, and they did. The trouble is not that they are old. It is that every change is expensive, the people who know them are retiring, and the public now expects to do things from a phone that the system was never built to allow.
The instinct is to replace it. The record of big-bang replacements in government is poor, and the reason is structural: a replacement has to reproduce every rule the old system enforces, many of which nobody has written down, and it has to do so before anyone can use it. That is a long time with nothing to show and a hard cutover at the end.
There is another way, and it is the one we use.
Put a new front door on the old system
The first deliverable is not a new system. It is an interface layer, an API, in front of the existing one. It reads and writes the same records the old system does, through whatever the old system offers: a database, a file drop, an existing integration, or in the worst case, a screen.
Once that layer exists, new things can be built against it without touching the old core. A public portal where residents check a permit's status. A mobile form an inspector fills on site that lands in the same case. A dashboard the director asked for three years ago. Each one is small, each one ships in weeks, and none of them requires the old system to change.
Move one workflow at a time
With the front door in place, the workflows behind it can move at the pace the agency can absorb. Pick the one that hurts most or the one that is simplest. Rebuild it on the new side. Run both for a period, with the new side writing back to the old records so nothing is lost. When the numbers match and the staff prefer the new one, the old path is retired.
Then the next workflow. There is never a weekend where everything changes, never a moment where the old system is turned off before the new one has earned it, and at every point the agency can stop and still have something better than it started with.
What the old system will not tell you
Every legacy system carries rules that exist only in its code and in the habits of the people who use it. The incremental path surfaces them one workflow at a time, when they can be checked with the people who know, rather than all at once in acceptance testing.
Our practice is to write each rule down as it is found, in plain language, and to make that document a deliverable. By the end, the agency owns a written description of how its own process works, which it did not have before, and which outlives any vendor.
What to ask for in the scope
- A written description of the current system's interfaces: what it exposes, what it does not, and how each record type will be reached.
- An order of workflows, with the reason for the order, and a definition of done for each one (usually: the same outcomes as the old path, measured over a defined period, with staff sign-off).
- Parallel-running periods with a written comparison at the end of each.
- Documentation as a deliverable at every step: the rules found, the as-built design, the runbook.
- No cutover date for the whole system. A retirement date for each workflow, set when its replacement has proven itself.
Security and accessibility are not separate tracks
The new front door is the place to get authentication, audit logging, and role-based access right once, so every new workflow inherits them. It is also where public-facing screens meet Section 508 and where the agency's records rules are applied. Doing these in the layer, rather than per screen, is most of the reason the later workflows go faster than the first.
Working with us
We build and modernize case management, portals, and APIs for state, local, and federal agencies, one workflow at a time, without downtime. If you have a system like this, tell us what you're working on. An engineer replies within one business day.