Almost everything written about the Web AppBuilder retirement, including by people who sell migrations, frames it as a rebuild exercise. Count your applications, migrate your applications, done.
For a good share of most portfolios that is the wrong frame. The question is not "how do we move this" but "should this exist".
We sell migration work, so this article costs us money to publish. We publish it because the alternative is invoicing clients to rebuild applications nobody opens, and that tends to be noticed eventually.
Retirement is an outcome, not a failure
Esri's own guidance lists possible destinations for a Web AppBuilder application: Experience Builder, Instant Apps, Dashboards, StoryMaps, a custom application. What tends to get left off the list is the two cheapest options: switch it off, or fold it into another application.
Both are legitimate. Both are usually available. Neither requires anybody to build anything.
How to spot a retirement candidate in about a minute
You do not need a consultant for this, and you do not need to guess. Esri records a view count on every item.
Open any application's item page in ArcGIS Online and the number is there. Or query it directly:
https://www.arcgis.com/sharing/rest/content/items/{itemId}?f=json
The response includes numViews and modified. That is enough to triage a whole portfolio.
In our study of 14,978 public Web AppBuilder applications, the spread within single organizations was routinely extreme: applications with over a million lifetime views sitting in the same portfolio as applications with under 200. Same organization, same platform, four orders of magnitude apart in use.
A reasonable first pass:
- Negligible views and untouched for two years. Retirement candidate. Ask who owns it before deleting, but start from the assumption that it goes.
- Low views but recently modified. Somebody cares. Find out who and why before touching it.
- High views. Migrate properly, and test with real users.
Watch two traps. Embedded applications can show low direct views while being loaded inside a page that gets plenty of traffic, so check whether anything links to it. And seasonal applications, gritting routes, flood maps, election maps, look abandoned in the off-season and matter enormously for six weeks a year.
The consolidation case, which is bigger than most people expect
The most common pattern we see is near-identical applications. Same widgets, same theme, same base layers, differing only in extent or which layers are switched on. Usually because it was quicker to copy an existing app than to add a filter to it.
Our dataset makes the shape of this visible. Thirteen widgets appear in more than 80% of all applications. The median application has three operational layers. When that many applications are built from the same small set of parts, a lot of them are variations rather than distinct things.
Five near-identical viewers merged into one configurable application is not just cheaper to build. It is one thing to maintain, one thing to test, one thing to secure, and one thing to migrate the next time Esri retires something.
Signals that you are looking at consolidation candidates:
- Same theme and near-identical widget list.
- The underlying web maps share most of their layers.
- Titles that differ by a place name, a year, or a version suffix. "Development Plan 2022-2028", "Development Plan 2022-2028 v2", "Development Plan Public".
- Created within days of each other.
- One has far more use than the others, which usually means the others were experiments that never got cleaned up.
That last pattern is worth dwelling on. A cluster of low-use applications around one popular one is normally the trail left by iteration, not five things people need.
What genuinely needs a proper rebuild
To be clear that this is not an argument for deleting everything:
- Anything with an editing workflow. If users write data through it, it is operational and it needs care. Only 7.3% of public applications expose editing, but internally the share is much higher.
- Anything with an external integration. 27.4% of applications authorise a cross-origin domain. Those are load-bearing connections to other systems.
- Anything with a genuine custom widget. Rare, three applications in 14,978, but decisive when present.
- Anything with high, sustained use in a statutory process. Planning registers, flood risk, licensing. These are the ones where downtime is a public-facing problem.
The order of operations that saves the most money
- Pull view counts for every application. Public and private. It is one API call each.
- Mark the negligible ones for retirement. Confirm ownership, do not just delete.
- Group the near-identical ones. Decide which single application replaces each cluster.
- Count what is left. This is usually a much smaller number than the one you started with, and it is the only number worth pricing.
- Then plan the migrations, hardest first, because those are the ones that will slip.
Most migration plans start at step five with the original application count. That is the expensive way round.
A word on the deadline
For Web AppBuilder in ArcGIS Online, editing existing applications stops in Q4 2026 and applications stop working in Q2 2027. Self-hosted ArcGIS Enterprise has no shutdown date at all, which we wrote about separately because the two get conflated constantly.
Deadlines encourage rebuilding things rather than thinking about them. Retiring an application takes an afternoon and needs no development capacity, so it is the one option that actually gets easier as the deadline approaches, not harder. Do that part first.
If you want this done properly across a portfolio, including the private applications, our five-day Blueprint covers it and will tell you plainly which applications we think should be switched off. That recommendation is not a discount on the assessment. It is the most valuable part of it.
