ArcGIS Web AppBuilder retirement: From application migration to platform strategy

ArcGIS Web AppBuilder (WAB) retirement is often discussed as an application migration task. In practice, it’s a broader platform strategy issue with two distinct drivers; ArcGIS Online retirement deadlines, and ArcGIS Enterprise upgrade constraints.

1) The published timelines are now concrete

Esri’s retirement roadmap sets out staged changes for ArcGIS Web AppBuilder in ArcGIS Online, creation of new apps ended in Q1 2026, app updates end in Q4 2026, and apps will be fully retired Q2 2027. These aren’t abstract dates; they align to ArcGIS Online release cycles and create a hard deadline for the many organizations with an operational dependence on WAB apps.

2) Enterprise environments face an ‘upgrade blocker’

For ArcGIS Enterprise, ArcGIS Enterprise 11.5 was the last release to include Web AppBuilder, meaning it is no longer available beginning with ArcGIS Enterprise 12.0. That means any organization that needs WAB to keep critical apps running may be anchored on 11.5, delaying upgrades, compounding technical debt, and limiting access to the newest platform capabilities.

One of the themes that emerged strongly during discussions at Esri UC was that many ArcGIS Enterprise customers are still earlier in their modernization journey than often assumed. While some organizations are already planning for ArcGIS Enterprise 12.x, many are currently operating on ArcGIS Enterprise 10.8.1, 10.9.1, 11.0 or 11.1.

For these organizations, the immediate objective is often a move to ArcGIS Enterprise 11.5, which delivers the broadest set of ArcGIS Experience Builder capabilities available within the 11.x generation while remaining the final ArcGIS Enterprise release to include Web AppBuilder. This creates an important transition period where organizations can continue supporting critical Web AppBuilder applications while actively expanding their use of Experience Builder.

As a result, many upgrade programs are now following a staged pathway:

ArcGIS Enterprise 10.x or early 11.x

→ ArcGIS Enterprise 11.5

→ Experience Builder adoption and application modernization

→ ArcGIS Enterprise 12.x and beyond

This is one of the reasons Web AppBuilder migration has become a strategic topic. The challenge is not simply replacing applications before retirement dates arrive. It is ensuring that Web AppBuilder dependencies do not slow broader ArcGIS Enterprise modernization programs, technology refresh initiatives, and future upgrade paths. 

3) The real challenge is portfolio governance

Most organizations don’t have one Web AppBuilder app, they have a portfolio. Apps proliferate because they’re useful, easy to clone, and were often created by different teams over time. The result is a familiar set of questions:

- Which apps exist across the organization?

- Who owns them?

- When were they last used, and by how many people?

- Which services, layers, and groups do they depend on?

- Which widgets or custom components will complicate migration?

Without answers, migration planning becomes guesswork. And guesswork creates risk; underestimated effort, missed dependencies, and unexpected stakeholder resistance.

4) ArcGIS Experience Builder is the common path, but not a single-step conversion

The most common path we see customers adopt is to migrate to ArcGIS Experience Builder. Esri has published a widget functionality matrix that lists every WAB widget mapped to the Experience Builder equivalent, where available. This includes the version of the widget that was introduced which can prove a key consideration for ArcGIS Enterprise customers on 11.2, or earlier, with many moving to 11.5 as interim step in order to take advantage of the greater number of Experience Builder widgets available. In this matrix Esri has also highlighted where a one-to-one parity does not exist and provides a link to recommended migration paths for unplanned widgets. Together, this matters because it turns app migration into a set of design decisions (replace, redesign, rebuild) rather than a simple update exercise.

5) A practical strategy: discover → rationalize → migrate

A robust migration program typically follows three phases:

Phase A — Discover

Create a complete inventory of WAB apps across ArcGIS, including widget usage and dependencies.

Phase B — Rationalize

Segment apps into *migrate*, *consolidate*, or *retire*, based on usage, business value, and complexity. Many organizations find a meaningful percentage of apps can be retired once usage and ownership are clarified.

Phase C — Migrate (at scale)

For the apps you keep, use repeatable patterns and automation to generate Experience Builder starting points—then focus expert effort on exceptions (custom widgets, UX upgrades, governance and testing).

Where Web AppBuilder Migrate fits

Web AppBuilder Migrate supports the stages that tend to consume the most time in large portfolios: discovery and the creation of Experience Builder starting points. Used well, it reduces uncertainty early and enables a more predictable delivery model.

Bottom line: treat WAB retirement as a platform program. The organizations that succeed are those that create portfolio visibility, make deliberate decisions about what to keep, and scale the migration with repeatable patterns.

To learn more about how Web AppBuilder Migrate helps organizations assess, prioritize, and accelerate ArcGIS Experience Builder adoption, read ArcGIS Web AppBuilder to Experience Builder in Seconds