Every conversation about the Web AppBuilder retirement runs on assumptions. That migrations are hard. That custom widgets are everywhere. That Experience Builder covers it. We could not find anyone who had actually measured what is inside real applications, so we did.
This is what we found in 14,978 publicly shared Web AppBuilder applications across 921 organizations in the United Kingdom, Ireland, Germany, Austria, Switzerland and the United States, read from each application's own published configuration in July 2026.
Some of it is reassuring. One finding is not, and it is the one nobody is talking about.
Method, briefly
Every Web AppBuilder application publishes its own configuration: the widgets it uses, the theme it runs on, and the web map behind it. That is public for any publicly shared app, and it is what a browser reads to draw the thing.
We queried Esri's public Sharing REST API for items typed as Web AppBuilder applications, resolved which organization owned each one, filtered by the organization's registered country, then read each application's configuration and its web map. No authentication was used and no secured resource was touched. Full limitations are at the bottom, and they matter.
Finding 1: 93.9% of apps rely on a widget Esri documents as not at parity
This is the headline, and it needs two sources to see.
Esri publishes a widget functionality matrix and a guide for Web AppBuilder users moving to Experience Builder. Both are candid about where Experience Builder does not yet match. To Esri's credit, they document it rather than hide it.
What nobody has done is check those documented gaps against what real applications actually use. When you do:
| Widget | Apps using it | Limitation Esri documents in Experience Builder |
|---|---|---|
| Attribute Table | 13,214 (88.2%) | Cannot be opened from the Layer List; per-layer visibility in the table is not configurable as it is in Web AppBuilder |
| Basemap Gallery | 6,597 (44.0%) | Creating new basemaps in the widget is not planned for Experience Builder |
| Share | 1,707 (11.4%) | Present, but not at full Web AppBuilder capability |
| Select | 877 (5.9%) | No control over which layers are selectable |
| Edit | 795 (5.3%) | Geometry split and merge are not available |
| Add Data | 715 (4.8%) | Present, but not at full Web AppBuilder capability |
14,058 of 14,978 applications, or 93.9%, use at least one of these.
Read that carefully, because it is easy to over-claim. It does not mean 94% of migrations will fail, or that those apps cannot move. Most of these gaps are minor for most apps, and Esri is actively closing them. What it means is that the odds of a genuinely like-for-like migration are low, and the single most common widget in the entire dataset is also the one with the most substantive documented gap.
If your migration plan assumes users will not notice the difference, that assumption is where it breaks. The Attribute Table one is not cosmetic: if your users are used to opening a table straight from the layer list, they will notice on day one.
Finding 2: we added two more territories expecting differences, and there are almost none
The first version of this study covered the UK and Ireland only. The obvious criticism was that British planning portals are not the world, so we extended it to the German-speaking countries and the United States to find out where the numbers moved.
They barely move.
| UK & Ireland | DACH | United States | |
|---|---|---|---|
| Applications read | 4,629 | 1,341 | 8,989 |
| Uses a widget with a documented Esri gap | 91.5% | 91.4% | 95.4% |
| Uses the Attribute Table | 87.9% | 75.8% | 90.2% |
| Reaches a cross-origin domain | 24.0% | 27.6% | 29.0% |
| Exposes an editing widget | 5.8% | 6.0% | 8.3% |
| Uses a widget outside Esri's standard sets | 0.0% | 0.1% | 0.0% |
| Median operational layers | 3 | 2 | 4 |
The parity-gap exposure sits between 91% and 96% in every territory. Cross-origin dependency sits in the twenties everywhere, and when you compare only applications with real usage it converges tighter still, to 30.4%, 33.3% and 33.2%. Custom widgets are absent everywhere.
That is a more useful result than a regional curiosity would have been. Guidance built on one country's data appears to generalise, which means you can calibrate against these numbers wherever you are.
Two differences do survive scrutiny. German-language applications use the Attribute Table noticeably less (75.8% against 87.9% and 90.2%), and editing widgets are roughly twice as common in American public applications as in British and Irish ones. Both hold when we restrict the comparison to applications with real traffic, so they are not artifacts of how deeply we searched each region. Restricted that way the gap figures are 89.2%, 91.9% and 95.6%.
We are deliberately not publishing a comparison of portfolio sizes between countries, even though we have the numbers, because our search reached each region differently and that metric would be measuring our own queries rather than the world.
Finding 3: most apps are much smaller than the anxiety suggests
The median application has four operational layers. Not forty. Four.
- 6,992 applications, 47% of the dataset, have three layers or fewer.
- Mean is 6.8, pulled up by a long tail.
- The largest has 491.
The same pattern shows in widgets. There are 80 distinct widgets in use across the dataset, but the distribution is brutally top-heavy. Thirteen widgets appear in more than 80% of applications:
| Widget | Share of apps |
|---|---|
| Coordinate | 100.0% |
| Splash | 99.8% |
| Zoom Slider | 98.9% |
| Overview Map | 98.6% |
| Scalebar | 98.6% |
| My Location | 97.5% |
| Search | 96.8% |
| Home Button | 96.4% |
| Extent Navigate | 91.1% |
| Attribute Table | 88.2% |
| Full Screen | 87.3% |
| Legend | 86.4% |
| Layer List | 85.1% |
Most of that top block is Web AppBuilder's default furniture rather than a deliberate choice. Below it the distribution drops away fast: Basemap Gallery 44.0%, Print 26.0%, Measurement 24.8%.
The practical read: the average public Web AppBuilder app is a map, a handful of layers, a legend, a search box and a table. That is not a hard rebuild. Treating every application in a portfolio as a bespoke project is how migration budgets get inflated, and it is why a per-application flat rate is often the wrong shape for the work.
Finding 4: the custom widget nightmare is a myth, and we previously overstated it
The received wisdom is that custom widgets are the thing that will hurt. In this dataset:
3 applications out of 14,978 use a widget that is not in Esri's documented standard sets.
Three. And because there are only three, we can name them:
- Stadt Cottbus runs an ALKIS cadastral widget from a German GIS vendor.
- Esri UK has a planning app using CycloMedia's Street Smart imagery widget.
- Geological Survey Ireland has a seabed data viewer with six non-standard widgets (
AddService,ElevationProfile,Identify,PopupPanel,SaveSession,UrlButton), which is what a genuinely bespoke application looks like.
Two of the three are commercial third-party products rather than in-house code. Only one of nearly fifteen thousand applications looks custom-built in the way the folklore describes.
An earlier version of this article reported nine applications out of 2,202. That figure was wrong and we are correcting it rather than quietly adjusting it. Our reference list of standard widgets came from Esri's widget overview for 2D apps and omitted the separate set that ships for 3D scene apps, so Home, Measurement3D and Environment were being counted as candidate custom code. They are stock. Correcting the list moved the count from 90 apps to three, and it also removed an apparent finding that German organizations used ten times more custom code than British ones, which turned out to be nothing more than German portfolios containing more 3D city models.
We remain deliberately careful with this number in the other direction too. A widget name outside Esri's published lists could be custom-developed, third-party, or a stock widget under a name we have not catalogued, and public information cannot distinguish those. So treat this as an upper bound on custom code in public apps, not a confirmed count.
Either way, if you have been putting off planning because you are afraid of what your developers built in 2018, the odds say you probably do not have that problem. Check rather than assume, because when custom code does exist it dominates everything else about the project. But it is genuinely rare.
Finding 5: external integrations are the real hidden dependency
Here is the one that surprised us. 4,101 applications, 27.4%, authorise at least one cross-origin domain.
That means more than a quarter of these applications talk to something outside ArcGIS. Another system, another agency's service, a bespoke endpoint somebody stood up years ago. Among applications with real traffic it is a third.
That is well over a thousand times more common than custom widgets, and we have not seen it discussed anywhere. It is also harder to plan for, because the dependency is not yours: it belongs to another team, another supplier, or another organization entirely, each with its own timetable and its own opinion about being asked to change.
If you inventory one thing before planning a migration, inventory this.
Finding 6: editing is rare in public apps, and that tells you where the cost is
Only 1,099 applications, 7.3%, expose an editing widget.
That is not because organizations do not edit data through Web AppBuilder. It is because editing requires authentication, so those applications are not public and we cannot see them.
This is the most important limitation of this study and we want to be blunt about it. Everything above describes the public half of the world: planning registers, flood maps, parcel viewers, recycling points. The applications that are genuinely expensive to migrate, the ones with editing workflows, secured services, single sign-on and bespoke integrations, sit behind a login.
The expansion made this sharper rather than softer. Across three separate sweeps covering thousands of candidate organizations, our method found essentially no self-hosted ArcGIS Enterprise portals at all. Enterprise portals are not listed in the ArcGIS Online index, so a public search cannot reach them: the only two in this dataset arrived because we already knew their hostnames. Since editing, single sign-on and secured services concentrate exactly there, the part of the world that is expensive to migrate is the part this method is structurally blind to.
So if you read this and conclude your migration looks manageable, please check that against your own internal portfolio first. The public apps are the easy half, by construction.
What we would take from this
- Inventory external integrations before anything else. More than a quarter of apps have one, a third among apps in real use, they are the dependency you do not control, and they have the longest lead time.
- Do not price per application. Nearly half these apps have three layers or fewer, and one has 491. A flat per-app rate overcharges for the simple ones and badly underprices the monsters.
- Check the Attribute Table behaviour early with actual users. It is in 88% of apps and it has the most substantive documented gap. It is the likeliest source of "this used to work" after go-live.
- Do not assume custom widgets. Confirm it. The odds are overwhelmingly in your favour and it changes the whole plan.
- Count your private apps. Any number derived from public applications, including every number in this article, is a floor.
Limitations
Stated plainly, because research without limitations is marketing:
- Public applications only. Anything not shared publicly is invisible here. As above, that biases the dataset towards simpler apps, and it is why the editing figure should not be read as an editing rate.
- Self-hosted Enterprise portals are structurally absent. They are not in the ArcGIS Online index. Two appear here only because we supplied their hostnames directly. This is the single biggest gap in the dataset.
- Six countries, unevenly sampled. The United States figures come from a seeded random sample of 500 organizations drawn from roughly 2,700 we discovered, because verifying every one would have meant hundreds of thousands of API calls for no statistical gain. The sample is random rather than largest-first, which would have biased it towards big atypical applications. UK, Ireland and the German-speaking countries are close to exhaustive for publicly shared apps we could find.
- Search reached each region by different routes. German-language applications could be enumerated in full because that query fits inside the API's result cap; English-language ones exceed it and had to be sampled by recency and popularity. We therefore compare regions on app-level measures only, and only where the difference survives restricting to applications with real traffic.
- We collected at most 100 applications per organization. 31 organizations hit that cap, so their real portfolios are larger and the dataset undercounts total volume. For the same reason we are not publishing a "largest portfolio" figure, because it would be an artifact of our own limit.
- 14,978 configurations read from 15,715 applications found. The remaining 737 would not load anonymously, which is itself mildly informative.
- A snapshot taken in July 2026. Esri is actively closing Experience Builder gaps, so the parity table above will improve. Re-check it against Esri's matrix rather than trusting this table later.
- Widget names are an imperfect proxy for what a widget does, and cannot prove custom code either way. We got this wrong once already, as described in Finding 4.
Corrections
This article has been corrected twice, and we would rather show that than hide it:
- Custom widget count. Previously "9 applications, 0.4%". Our standard-widget list omitted Web AppBuilder's 3D scene widgets, so three stock widgets were being counted as candidate custom code. Now 3 applications out of 14,978, all named in Finding 4.
- Editing widgets. An early version, drawn from a 117-app sample, said 1% and that none used non-standard widgets. Both were too absolute for the sample size.
Reproducing this
Every figure comes from Esri's public API. The queries are type:"Web Mapping Application" AND typekeywords:"Web AppBuilder" against sharing/rest/search, then sharing/rest/content/items/{id}/data for each configuration. The culture: field is searchable and is the practical way to reach non-English applications. If you want your own organization's numbers, that is two API calls and some counting.
If you would rather not, our five-day modernization Blueprint does it properly, including the private applications this study cannot see.
Sources
- Individual widget functionality matrix between Web AppBuilder and Experience Builder, Esri Community
- Experience Builder for Web AppBuilder users, Esri documentation
- ArcGIS Web AppBuilder retirement, Esri documentation
- ArcGIS Web AppBuilder widget overview, Esri documentation, used as the reference list of standard 2D widgets
- ArcGIS Web AppBuilder 3D widget overview, Esri documentation, the 3D set we originally omitted
Mapular is an Esri partner with the Nonprofit Specialty. We built the UNESCO World Heritage Site Navigator with Esri Deutschland on ArcGIS Experience Builder, Dashboards and Notebooks, monitoring more than 1,000 inscribed properties. If you spot an error in this data, we would genuinely like to know: hello@mapular.com.
