5 ways GIS is modernizing across the public sector
Public sector GIS teams are being asked to do more with the same headcount. At the same time, several of the tools underneath them are reaching end-of-life status. ArcMap retired in March. Configurable Apps were scheduled for removal from ArcGIS Online in February. Web AppBuilder apps stop being editable in Q4 2026 and stop working entirely in Q2 2027.
When that much changes in a short space of time, it surfaces questions. What is working well? What has our team outgrown? Which parts of the service would look different if you were designing them today, from scratch?
Those are good questions to sit with, and plenty of agencies are already working through them in ways worth borrowing. Here are five patterns showing up across the public sector, plus one action you can take for each one to start modernizing your GIS.
1. Treating a retirement notice as a reason to ask who the app was really for
Public sector GIS accumulates. There is a data viewer somebody asked for in 2017, a workflow set up by a contractor who left two years ago, and a dashboard that three people have open right now… but they don’t realize it’s running on stale data. It all keeps running, so none of it gets questioned.
A forced migration is the best moment you will ever get to ask whether the thing is still needed. A great example of this is Esri sunsetting Web AppBuilder. Plenty of public sector organizations are already working through this in the open, such as Ohio State’s retirement guidance for its own users. The agencies who are getting real value out of that deadline are treating it as an audit rather than a port. Some apps turn out to have no users. Some should have been one page all along. Some are worth rebuilding properly, with the people who actually use them in the room.
Do this today: Pull usage statistics for every app on a retirement list before you scope a single migration. Some of them will have no users at all, and switching those off is the fastest win available to you.
2. Analyzing data where it already sits
Most agencies have spent years consolidating their data into a warehouse or a database they already own, secure, and audit. And the GIS data? That’s copied back out of it into a separate environment that is compatible with their GIS software. Now there are two copies, two sets of permissions, and a map that is a day (at least!) behind the record it was built from.
That gap is the most common complaint in the field. In our State of Spatial Analytics research, nearly 30% of respondents named data access and integration delays as their single biggest obstacle.
The alternative is to run the spatial analysis against the original, centralized and fresh data. This is less exotic than it sounds. BigQuery, Snowflake, Databricks, Redshift and Oracle all support spatial data natively today. When a cloud-native platform like CARTO can run the analysis where the data already lives, there is nothing to sync. That means nothing to maintain, and a map that cannot drift out of date, because there is only ever one version of the data underneath it.
Do this today: Find a dataset that is duplicated across different databases, and find out if it’s exactly the same, down to the row. Ask your data team which spatial datasets currently exist in two places, and what the sync interval is on each. The interval is usually longer than anyone in the room assumed.
3. Determining who can see what, and being able to prove it
Governance questions rarely arrive on a schedule. They come with a freedom of information request or an internal audit, and what they ask is not where the data sits but who could see it, and when. That is a hard thing to answer when permissions were set in two places, by two teams, at two different times.
Keeping the analysis in one place settles most of it as a side effect, because the permissions and the audit trail are the ones the organization already maintains rather than a second set living somewhere else. CARTO is built around that. It runs inside your own warehouse and makes no copy of your data. It inherits the role-based access control and row-level security your team has already configured, people sign in through your existing SSO with groups synced from your identity provider, and every query is auditable.
This extends to CARTO’s AI Agents. An agent’s access and permissions always reflect those of the person using it, so it can never surface a record they could not see for themselves, or take an action they could not take.
Do this today: That dataset which is duplicated across different databases? Compare who can see it in each. The gap between the two lists is the problem.
4. Turning the specialist queue into self-service
Two or three GIS staff serving several hundred people across planning, public health, transport, housing, and communications is a common shape, and the constraint is almost never skill. It’s the queue. By the time a request has worked its way to the front of it, the committee has already met and the decision is made.
Self-service does not mean everybody starts making their own maps. The specialists still own cartographic quality, authoritative data, and anything going in front of a council, an inspector, or a court, and that should not change. What changes is what happens to the ad-hoc questions, such as “how many properties sit within 500 meters of this site?” It’s a question the person asking it can answer in a minute, if an analyst has built them a way to ask it.
In practice, this means an analyst packaging a piece of their own expertise into an AI Agent, sitting on top of a map they still own and control. The analyst is not doing less. Their judgment now reaches everybody who asks, instead of being spent one request at a time. One transportation agency using CARTO went from running this kind of analysis once a week to multiple times a day, with non-technical teams able to run it themselves rather than waiting on the GIS team.
Do this today: Log every incoming request for two weeks and tag each one as routine or genuinely analytical. The ratio tends to surprise people, and it tells you exactly which questions can be built into a self-service solution.
5. Opening GIS up to the rest of the organization
GIS has often run as a closed function. Its own tools, its own file formats, its own team, its own budget line. It produces maps that get exported and pasted into somebody else’s slides, which means it’s consulted late and gets treated as a technical service. Teams doing spatial work typically rely on between three and eight separate tools, which is a large part of why spatial analysis ends up walled off from everything else.
In the agencies where GIS has become strategic, spatial data flows into the tools everyone else already uses: the reporting stack that carries performance data, the BI dashboard a director opens on Monday morning, the AI assistant a policy team is already asking questions in. Open standards make that ordinary rather than a project. GIS stops being a place people have to go and becomes a layer in the things they already do, which is also how it stops being the first line cut when budgets tighten.
Do this today: Take one number your leadership already tracks and add a spatial dimension to it, inside whatever tool they already look at.
How CARTO helps
CARTO is the leading Agentic GIS platform, and it is built to help public sector agencies modernize how they work with spatial data. It runs inside the cloud data warehouse or database an agency already has, so the analysis happens where the data lives and the data itself never moves or gets copied out.
From there, teams build maps, applications, analytical workflows and AI Agents, all of which can be built and used from inside the AI platforms agencies already run, including Microsoft Copilot, Oracle Agent Factory and Gemini Enterprise. That might mean scoring urban heat exposure street by street, or working out how far residents really are from a healthcare facility, with none of the underlying data ever leaving your cloud.
Where to start
The teams building the most successful GIS functions are rarely the ones with the biggest budgets. They are the ones who started challenging the status quo and built the tools their agency actually needs, in a way they can easily use. That’s what you’ll use CARTO for.
Request a demo to learn how modernizing could turn GIS into your agency’s superpower, or start with a free ArcGIS migration assessment.
Frequently Asked Questions
How should public sector agencies approach Esri app retirements like Web AppBuilder?
Treat the retirement as an audit rather than a port. Pull usage statistics for every app on a retirement list before scoping a single migration: some will have no users and can simply be switched off, some should have been one page all along, and some are worth rebuilding properly with the people who actually use them.
Why analyze GIS data directly in the data warehouse?
Copying data out of a warehouse into a separate GIS environment creates two copies, two sets of permissions, and a map that lags behind the record it was built from. BigQuery, Snowflake, Databricks, Redshift and Oracle all support spatial data natively, so a cloud-native platform like CARTO can run the analysis where the data already lives, with nothing to sync.
How does CARTO handle data governance and permissions for government agencies?
CARTO runs inside the agency’s own warehouse and makes no copy of the data. It inherits the role-based access control and row-level security already configured there, signs people in through existing SSO with groups synced from the identity provider, and makes every query auditable. CARTO AI Agents act with the same permissions as the person using them.
Does self-service GIS replace the GIS team?
No. Specialists still own cartographic quality, authoritative data, and anything that goes in front of a council, an inspector or a court. What changes is the ad-hoc questions: an analyst can package their expertise into an AI Agent on top of a map they control, so colleagues answer routine questions themselves instead of waiting in the queue.
