There are commercial tools that will convert a Web AppBuilder application into an Experience Builder application for roughly USD 25 per application. Geovonic Migrate and Cartinuum's Web AppBuilder Migrate are the two we see most.
We are a consultancy that sells migration work, so the expected move here is to explain why you need a human. Instead: for a meaningful share of most portfolios, you should try the converter first. It is cheaper than the meeting you would hold about whether to try it.
What follows is where the boundary actually sits, because that is the useful information and nobody with a commercial interest on either side is publishing it.
Where a converter is the right call
From our study of 14,978 public Web AppBuilder applications, the median application has four operational layers and is built from a set of thirteen widgets that appear in over 80% of all applications: coordinates, splash screen, overview map, scalebar, zoom, home, search, location, extent navigation, full screen, attribute table, layer list, legend.
That is a map with a few layers, a search box and a table. Nearly half the dataset has three layers or fewer.
For an application like that, a converter is doing exactly the job it was built for: take a known widget set, produce the equivalent layout. There is no judgment required, nothing bespoke, and no reason to pay a person to do it.
If your portfolio is a dozen simple public viewers, buy the tool. Genuinely.
Where a converter structurally cannot help
Not "does it badly". Cannot, in the sense that the problem is not a conversion problem.
It cannot decide anything
A converter converts what you point it at. It has no opinion on whether the application should exist.
This is the big one, because the cheapest outcome for most portfolios is fewer applications. Retiring an unused application costs nothing and takes an afternoon. Merging five near-identical viewers into one configurable application removes four things to maintain forever. A converter faithfully reproducing five near-identical applications has done its job correctly and left you worse off than a decision would have.
We wrote about which applications not to migrate separately. At USD 25 each, converting applications you should have switched off is cheap. Maintaining them for another five years is not.
It cannot see your secured services
A converter works on what it can read. If an application depends on a secured feature service, an authenticated geoprocessing service, or a layer behind single sign-on, the conversion may complete and the result may not work, or may work only for whoever tested it.
More than a quarter of the applications in our dataset, 27.4%, authorise at least one cross-origin domain, and a third of those in active use. Those integrations are the most common non-trivial dependency in real portfolios, and they are exactly the sort of thing that either converts cleanly or produces a broken app with no obvious error.
It cannot migrate custom code
If an application uses a genuinely custom widget, there is nothing to convert to. Web AppBuilder Developer Edition was retired in July 2024, along with the ArcGIS API for JavaScript 3.x version those widgets were written against. Custom behaviour has to be rebuilt against the Experience Builder framework or the ArcGIS Maps SDK.
In fairness, this is rare. Three applications out of 14,978 we examined used a widget outside Esri's documented standard sets, and two of those were commercial third-party products rather than in-house code. Do not let the fear of this delay your planning. But do check, because when it is present it determines the shape of the whole project.
It cannot close a parity gap that Esri has not closed
This is the limitation people notice after go-live rather than during.
Esri documents where Experience Builder does not yet match Web AppBuilder. 14,058 of the 14,978 applications we examined, 93.9%, use at least one widget with a documented limitation. The largest by far is the Attribute Table, in 88.2% of applications, which in Experience Builder cannot be opened from the Layer List and does not offer the same per-layer visibility control.
A converter cannot invent functionality Experience Builder does not have. It will produce a valid Experience Builder application with the behaviour Experience Builder supports. Whether your users accept that difference is a conversation, not a conversion setting, and it needs having before you migrate the application they use every day rather than after.
It cannot choose a different target platform
A converter's output is an Experience Builder application, because that is what it converts to. But Experience Builder is not always the right destination. A read-only viewer with a small widget surface is often better as an Instant App, which is considerably less to maintain. Something whose real job is monitoring belongs in Dashboards. Something communicating a narrative belongs in StoryMaps.
Converting everything to Experience Builder is a defensible default. It is not an assessment.
How to tell which side an application falls on
Four questions, in this order:
- Does anyone use it? Check
numViewson the item. If not, retirement beats conversion at any price. - Is it near-identical to another application? If so, consolidate rather than convert both.
- Does it write data, or reach outside ArcGIS? Editing widgets or cross-origin domains mean a person needs to look at it.
- Does it use a widget that is not on Esri's standard list? If yes, there may be custom code, and a converter has nothing to work with.
Four "no" answers plus real usage means try the converter. Any "yes" in questions three or four means the application needs a decision before it needs a tool.
The honest summary
Converters are good value for simple applications and there are more simple applications than the discourse suggests. Use them there.
What they cannot do is the part that actually saves money: deciding what should exist, spotting what can merge, finding what will break because of a dependency you do not control, and choosing a target platform per application rather than by default.
That is what our five-day modernization Blueprint is for, and one of its more common outputs is "these six can go through a converter, these two need work, and these four should be switched off". If that is the answer, we will say so, and you will have spent EUR 4,900 to avoid spending considerably more.
Prevalence figures are from our study of 14,978 public Web AppBuilder applications across 921 organizations in six countries, including its stated limitations. Parity limitations are as documented by Esri in the widget functionality matrix. We have no commercial relationship with any converter vendor named here and have not independently tested their output quality.
