Search for how long a Web AppBuilder migration takes and you will find nothing useful. Esri does not publish it, because they do not sell the work that way. Migration tool vendors do not publish it, because their answer is "buy the tool". Consultancies do not publish it, because they would rather scope it on a call.
We are a consultancy, so treat this as interested. But the silence is unhelpful enough that a straight answer is worth more than the negotiating advantage of withholding one.
We will not give you an hours figure. Anyone who gives you one without seeing your portfolio is guessing, and the honest version of this article is a breakdown of what actually drives the number. Where we can attach real prevalence data, we have, from our study of 14,978 Web AppBuilder applications.
The two prices already in the market
There are two public anchors, and they are three orders of magnitude apart.
Automated per-application converters, around USD 25 per app. Tools like Geovonic Migrate and Cartinuum's Web AppBuilder Migrate will take an application and produce an Experience Builder equivalent. At that price it is obviously worth trying.
Consultancy engagements, in the thousands. Our own modernization Blueprint is EUR 4,900 for up to three applications, and that is assessment and planning, not the rebuild.
Those are not competing offers, and if someone presents them as competing they are selling you something. A converter moves a layout. It cannot tell you which applications to retire, cannot see your secured services, cannot migrate custom code, and cannot decide anything. If your portfolio is genuinely twelve simple public viewers, the converter may be most of what you need. Try it first. We would rather you did.
What actually drives the cost
Ranked by how often each appears in real applications, because prevalence is what determines your portfolio's total, not the worst case.
1. External integrations, in 27.4% of apps
Nearly a third of applications authorise at least one cross-origin domain, meaning they talk to something outside ArcGIS.
This is the most expensive common factor and the most overlooked, because the dependency is not yours. It belongs to another team, another supplier, or another organization. Every one needs identifying, testing against the target platform, and often a conversation with someone who has no stake in your deadline and their own release cycle.
Effort here is dominated by coordination, not code. That makes it the hardest to compress and the easiest to underestimate.
2. Attribute Table behaviour, in 88.2% of apps
The most-used widget in the dataset after the navigation furniture, and the one with the most substantive gap Esri documents for Experience Builder: it cannot be opened from the Layer List, and per-layer visibility in the table is not configurable the way it is in Web AppBuilder.
For most applications this is a small adjustment plus a conversation with users. Across a portfolio of twenty applications it is twenty small adjustments and twenty conversations, and that is where the estimate quietly doubles.
3. Layer and popup configuration, median 4 but a long tail
Nearly half the applications in our dataset have three operational layers or fewer. 865 have more than twenty. One has 491.
Field aliases, visibility ranges, popup content and formatting are per-layer configuration and do not travel with the layer. So this factor scales linearly with layer count, which means your portfolio total depends almost entirely on where your applications sit in that distribution. Two organizations with ten applications each can differ by a factor of five.
4. Editing workflows, in 7.3% of public apps and far more internally
Rare in public applications because editing needs authentication, so this is understated by any public study including ours. If you edit data through Web AppBuilder, these are your expensive applications, and the cost is not the widget: it is editing templates, attribute rules, related records, per-layer permissions, and the user acceptance testing that has to follow.
Assume any application with editing is several times the effort of a read-only viewer of the same size.
5. Print, in 26.0% of apps
Depends on a print service and layout templates. Usually straightforward, occasionally a surprise when custom templates were installed server-side years ago and nobody remembers doing it.
6. Custom widgets, in 3 apps out of 14,978
Last, deliberately, because it dominates the conversation and almost never appears. Three applications out of 14,978.
When it does appear it changes everything, because custom code does not migrate by reconfiguration and Web AppBuilder Developer Edition was retired in July 2024 along with the JavaScript API version it was written against. The decisive question is whether the source still exists.
But plan for the 27.4% before the three-in-fifteen-thousand.
Why per-application pricing is the wrong shape
A flat rate per application is attractive because it is easy to compare. It is also, for most portfolios, wrong in both directions at once.
Nearly half these applications have three layers or fewer and a handful of standard widgets. A flat rate overcharges for those, and a converter probably handles them.
The tail is where the money is. An application with 491 layers, an editing workflow and two external integrations is not five times a simple viewer, it is a project. A flat rate underprices it badly, and an underpriced project gets delivered accordingly.
The other thing per-application pricing cannot do is subtract. Which brings us to the cheapest available saving.
The cheapest migration is the one you do not do
Two moves reduce a portfolio before anyone rebuilds anything:
Consolidation. Organizations accumulate near-identical viewers that differ only in extent or layer selection, usually because it was easier to copy an app than to add a filter. Merging five into one configurable application is cheaper than rebuilding five, and cheaper to maintain afterwards.
Retirement. Some applications are not used. Our dataset has applications with fewer than 200 lifetime views sitting in portfolios alongside apps with over a million. Esri's own item statistics will tell you which is which in about a minute.
We wrote separately about which applications not to migrate. It is the least commercially convenient thing we publish and the one that saves the most money.
What we would actually do
- Count the applications, including private ones. Public counts are a floor.
- Sort by usage. Esri publishes view counts per item. Anything with negligible use is a retirement candidate before it is a migration candidate.
- Find the near-duplicates. Consolidate before rebuilding.
- List every external integration. This has the longest lead time and you do not control it.
- Separate editing from read-only. They are different projects with different testing burdens.
- Try a converter on your simplest app. At USD 25 it is cheaper than a meeting about whether to try it.
- Get a fixed price on what remains, after the portfolio has shrunk.
If steps one to five sound like work you do not have time for, that is exactly what our five-day Blueprint is: EUR 4,900, up to three applications, ending in a fixed-price implementation proposal, and it covers the private applications a public study cannot see.
And if the answer is that most of your portfolio should be retired or consolidated, we will tell you that, which is generally the fastest way a Blueprint pays for itself.
Prevalence figures throughout are from our study of 14,978 public Web AppBuilder applications across 921 organizations in six countries, including its limitations. Parity limitations are as documented by Esri in the widget functionality matrix.
