Four systems that never spoke,
connected in a single portal.
A pattern common in local governments: four or more legacy cadastral systems recording the same territorial reality, with no single point of consultation. Here's how we'd address it — without replacing what works.
The cadaster exists four times. None of them is the truth.
In many city halls, four offices record the same territorial reality: the cadaster office has one database, the treasury another, planning a third, public works a fourth. Each built in a different era, with incompatible technologies, without synchronization.
The cost is passed to the citizen: when they request information about a property, an officer has to manually consult each source, reconcile differences, and issue a report. What should be a simple query takes weeks.
Replacing the systems is usually infeasible: each has users, processes, and institutional dependencies of its own. The solution has to coexist with what exists, not destroy it.
An integration layer, not a replacement.
The pattern we'd apply: design an intermediate layer that connects to the existing systems, reconciles their data with documented priority rules, and exposes a single API. The legacy systems keep operating as they always have.
The four typical phases we propose:
1. Discovery. Mapping the sources, interviews with users
of each office, technical audit, identification of canonical fields and
conflict rules.
2. Integration layer. Connectors per system, canonical data
model in PostGIS, documented and auditable reconciliation rules.
3. Citizen portal. Lightweight frontend, map with official
neighborhoods, search by ID, NIT, or cadastral reference.
4. Open API. OpenAPI documentation, rate limits, optional
authentication. Open data for researchers and developers.
Typical timing per phase depends on the state of the sources and the agreed scope.
A single portal. Four systems intact behind it.
At close, the municipality has: a citizen portal that responds in seconds, a documented API for researchers and developers, a defensible canonical data model, and the legacy systems still running — no migration, no replacement.
The reconciliation rules are documented and auditable: when two systems report different data for the same property, it's clear why one was chosen over the other.
And the municipal team can maintain it all without us — the code and the model are readable and inheritable.
Mature technologies, maintainable code.
Consolidated stack: nothing experimental, all documented, with strong ecosystem. The municipality's team can maintain it without us.
Legacy systems that don't talk?
Write to us.
Tell us the context and the systems involved — we respond with questions, not a closed proposal.