The Plumbing Layer: Why Most GIS Teams Stall on Modernization
Most GIS teams I work with have already tried to modernize. They have people on Python. Someone is running PostGIS. A few have touched DuckDB or Sedona. And the modernization still stalls.
The pattern: tools brought in, then abandoned
The pattern is consistent. A new tool gets brought in. Three months later it is abandoned. The person who championed it rotated off or moved on. Nobody else can pick it up because the data is still in the old places.
Re-export. Re-prep. Re-validate.
Then the next project starts and it all happens again.
It is not a tool problem
This is not a tool problem. The tools are mostly fine. The reason every modernization attempt stalls is one layer underneath the tools you brought in: the storage layer.
File geodatabases. Feature services. WMS endpoints. Shapefiles in shared drives. The messiest layer of the entire stack, and the one almost nobody designs.
I have been calling this the plumbing layer. It is invisible until something breaks. It is never the glamorous part of the project. And it is the part that decides whether the whole modernization works.
A note on the existing stack
Before going further, something needs to be said out loud. ArcGIS Pro runs 80% of GIS work in the world. It is still the right tool for cartography, editing, field collection, permitting, and a lot of analysis. The problem is not what sits at the top of the stack. The problem is what feeds it from underneath.
When the plumbing is messy, every tool on top of it inherits the mess. That is true for ArcGIS Pro, and it is true for Python.
The reframe
A modern spatial storage layer is not a replacement for ArcGIS Pro. It is a foundation that ArcGIS Pro sits on top of.
Cloud storage as the substrate. S3, GCS, or Azure Blob, whichever the org already uses. Do not fight the IT team on this one.
Open spatial formats on top. GeoParquet for vector. COG for raster. Iceberg or Delta tables when transactional control is needed.
Connection to open data. Source Cooperative, Overture Maps Foundation, STAC catalogs. Teams stop paying for basemap and POI data that is now open and refreshed weekly.
Pipelines that move data through Bronze, Silver, and Gold. Sedona or Wherobots for distributed work. SedonaDB or DuckDB for embedded. GDAL command line for the simpler transforms. Pick the tooling that matches the scale.
ArcGIS Pro reads GeoParquet directly. QGIS does. Python does. Tableau does. Nothing gets ripped out.
The piece nobody designs: data contracts
Now the part most teams skip.
A data contract is a page per dataset. Owner, schema, CRS, geometry validity, refresh cadence, SLA. Anyone on the team can read it. Anyone can update it.
Contracts at the Silver layer are the highest leverage. Silver is where the rest of the team consumes from. If Silver has contracts, the team can move. If it does not, every downstream user re-validates everything, and the team is back to two weeks of data prep at the start of every project.
This is not a technical problem. It is a design and discovery problem. The team has to decide what each dataset promises and then write it down.
This is team work, not solo work
The plumbing layer cannot be built by one person in isolation.
I have watched a lot of GIS leaders try to do this on the side. Build the storage layer in their nights and weekends. Convince one or two colleagues to try it. Then watch the rest of the team keep running the old workflow because nothing in the new system is contracted, documented, or visible to them.
The leader burns out. The system stalls. The org concludes that modernization is harder than it looked and goes back to the file geodatabase.
The plumbing layer is team work. Not solo work.
Where Spatial Lab for Teams fits
This is exactly the gap Spatial Lab for Teams was built to close.
A team gets the full Lab. Personalized roadmaps, a private team space, the practitioner community, the live sessions. And for orgs that want to design this storage layer with me directly, the custom training package is scoped specifically to that work. Architecture audit, medallion design, data contracts, implementation walkthrough on the team’s actual stack.
If the modernization has been one person carrying it and the team is not coming along, the answer is not a better tool. The answer is a plumbing layer the team designs together, contracts together, and runs together.
