Wir haben die Konfiguration von 14.978 Web AppBuilder Anwendungen ausgelesen. Das steckt wirklich darin

Jede Diskussion über die Abkündigung von Web AppBuilder läuft auf Annahmen. Dass Migrationen schwierig sind. Dass eigene Widgets überall stecken. Dass Experience Builder alles abdeckt. Wir haben niemanden gefunden, der tatsächlich gemessen hat, was in echten Anwendungen steckt. Also haben wir es getan.

Das ist, was wir in 14.978 öffentlich geteilten Web AppBuilder Anwendungen in 921 Organisationen gefunden haben, in Großbritannien, Irland, Deutschland, Österreich, der Schweiz und den USA, ausgelesen aus der jeweils eigenen veröffentlichten Konfiguration im Juli 2026.

Einiges davon ist beruhigend. Ein Befund ist es nicht, und genau über den spricht niemand.

Kurz zur Methode

Jede Web AppBuilder Anwendung veröffentlicht ihre eigene Konfiguration: die genutzten Widgets, das Theme und die dahinterliegende Webkarte. Das ist bei jeder öffentlich geteilten App einsehbar, und es ist genau das, was ein Browser liest, um die Anwendung darzustellen.

Wir haben Esris öffentliche Sharing REST API nach Items vom Typ Web AppBuilder abgefragt, für jedes die besitzende Organisation aufgelöst, nach dem eingetragenen Land der Organisation gefiltert und dann jede Konfiguration samt Webkarte gelesen. Es wurde keine Authentifizierung genutzt und keine geschützte Ressource berührt. Die vollständigen Einschränkungen stehen am Ende, und sie sind relevant.

Befund 1: 93,9 Prozent der Apps hängen an einem Widget, das Esri als nicht gleichwertig dokumentiert

Das ist die Kernaussage, und man braucht zwei Quellen, um sie zu sehen.

Esri veröffentlicht eine Widget-Funktionsmatrix und einen Leitfaden für Web AppBuilder Anwender, die zu Experience Builder wechseln. Beide sind offen darin, wo Experience Builder noch nicht mithält. Das ist Esri anzurechnen: Sie dokumentieren es, statt es zu verschweigen.

Was niemand getan hat: diese dokumentierten Lücken gegen das abgleichen, was echte Anwendungen tatsächlich nutzen. Wenn man das tut:

14.058 von 14.978 Anwendungen, also 93,9 Prozent, nutzen mindestens eines davon.

Das muss man genau lesen, denn es lädt zur Überinterpretation ein. Es bedeutet nicht, dass 94 Prozent der Migrationen scheitern oder dass diese Apps nicht umziehen können. Die meisten dieser Lücken sind für die meisten Apps unkritisch, und Esri schließt sie aktiv. Es bedeutet: die Chance auf eine wirklich deckungsgleiche Migration ist gering, und das häufigste Widget im gesamten Datensatz ist gleichzeitig das mit der substanziellsten dokumentierten Lücke.

Wenn Ihr Migrationsplan darauf setzt, dass Anwender den Unterschied nicht merken, dann bricht er genau dort. Die Sache mit der Attributtabelle ist nicht kosmetisch: Wer gewohnt ist, die Tabelle direkt aus der Layerliste zu öffnen, merkt das am ersten Tag.

Befund 2: Wir haben zwei Regionen ergänzt und Unterschiede erwartet. Es gibt fast keine

Die erste Fassung dieser Studie umfasste nur Großbritannien und Irland. Der naheliegende Einwand war, dass britische Planungsportale nicht die Welt sind. Also haben wir sie auf den deutschsprachigen Raum und die USA erweitert, um zu sehen, wo sich die Zahlen verschieben.

Sie verschieben sich kaum.

Die Parity-Lücke liegt in jedem Gebiet zwischen 91 und 96 Prozent. Externe Abhängigkeiten liegen überall in den Zwanzigern, und wenn man nur Anwendungen mit echter Nutzung vergleicht, rücken die Werte noch enger zusammen: 30,4 Prozent, 33,3 Prozent und 33,2 Prozent. Eigene Widgets fehlen überall.

Das ist ein nützlicheres Ergebnis als eine regionale Kuriosität. Empfehlungen, die auf den Daten eines Landes aufbauen, scheinen übertragbar zu sein, und das heißt, Sie können sich an diesen Zahlen orientieren, wo auch immer Sie sitzen.

Zwei Unterschiede halten der Prüfung stand. Deutschsprachige Anwendungen nutzen die Attributtabelle deutlich seltener (75,8 Prozent gegen 87,9 und 90,2 Prozent), und Bearbeitungs-Widgets sind in öffentlichen US-Anwendungen etwa doppelt so häufig wie in britischen und irischen. Beides bleibt bestehen, wenn wir den Vergleich auf Anwendungen mit echtem Traffic beschränken, ist also kein Artefakt der Suchtiefe je Region. So beschränkt liegen die Lückenwerte bei 89,2 Prozent, 91,9 Prozent und 95,6 Prozent.

Einen Vergleich der Portfoliogrößen zwischen Ländern veröffentlichen wir bewusst nicht, obwohl wir die Zahlen haben. Unsere Suche hat die Regionen unterschiedlich tief erreicht, und diese Kennzahl würde unsere eigenen Abfragen messen statt die Welt.

Befund 3: Die meisten Apps sind viel kleiner, als die Nervosität vermuten lässt

Die mittlere Anwendung hat vier operationale Layer. Nicht vierzig. Vier.

• 6.992 Anwendungen, 47 Prozent des Datensatzes, haben drei Layer oder weniger.
• Der Mittelwert liegt bei 6,8, hochgezogen von einem langen Ausläufer.
• Die größte hat 491.

Dasselbe Muster zeigt sich bei den Widgets. Es sind 80 verschiedene Widgets im Einsatz, aber die Verteilung ist extrem kopflastig. Dreizehn Widgets kommen in über 80 Prozent der Anwendungen vor:

Der Großteil dieses Blocks ist die Standardausstattung von Web AppBuilder und keine bewusste Entscheidung. Darunter fällt die Verteilung schnell ab: Basemap Gallery 44,0 Prozent, Print 26,0 Prozent, Measurement 24,8 Prozent.

Praktisch gelesen: die durchschnittliche öffentliche Web AppBuilder App ist eine Karte, eine Handvoll Layer, eine Legende, ein Suchfeld und eine Tabelle. Das ist kein schwerer Neubau. Jede Anwendung eines Bestands als eigenes Projekt zu behandeln, ist der Grund, warum Migrationsbudgets aufgeblasen werden, und deshalb ist ein Pauschalpreis pro Anwendung oft die falsche Form für diese Arbeit.

Befund 4: Der Schrecken eigener Widgets ist ein Mythos, und wir haben ihn selbst überzeichnet

Die verbreitete Annahme ist, dass eigene Widgets die schmerzhafte Stelle sind. In diesem Datensatz:

3 von 14.978 Anwendungen nutzen ein Widget, das nicht in Esris dokumentierten Standardumfängen steht.

Drei. Und weil es nur drei sind, können wir sie benennen:

• Stadt Cottbus betreibt ein ALKIS-Widget eines deutschen GIS-Anbieters.
• Esri UK hat eine Planungsanwendung mit dem Street-Smart-Widget von CycloMedia.
• Geological Survey Ireland hat einen Meeresbodenviewer mit sechs nicht standardmäßigen Widgets (AddService, ElevationProfile, Identify, PopupPanel, SaveSession, UrlButton), und so sieht eine tatsächlich individuell gebaute Anwendung aus.

Zwei der drei sind kommerzielle Produkte von Drittanbietern und kein selbst entwickelter Code. Nur eine von knapp fünfzehntausend Anwendungen sieht so individuell gebaut aus, wie es die Folklore behauptet.

Eine frühere Fassung dieses Artikels nannte neun Anwendungen von 2.202. Diese Zahl war falsch, und wir korrigieren sie, statt sie still anzupassen. Unsere Referenzliste der Standard-Widgets stammte aus Esris Widget-Übersicht für 2D-Apps und ließ den separaten Satz aus, der für 3D-Szenen mitgeliefert wird. Dadurch wurden Home, Measurement3D und Environment als Kandidaten für eigenen Code gezählt. Sie sind Standard. Die Korrektur der Liste senkte die Zahl von 90 Apps auf drei, und sie beseitigte außerdem einen scheinbaren Befund, deutsche Organisationen nutzten zehnmal mehr eigenen Code als britische. Tatsächlich enthalten deutsche Bestände nur mehr 3D-Stadtmodelle.

Wir bleiben auch in die andere Richtung vorsichtig. Ein Widget-Name außerhalb von Esris veröffentlichten Listen kann selbst entwickelt, von einem Drittanbieter oder ein Standard-Widget unter einem Namen sein, den wir nicht erfasst haben. Öffentliche Informationen können das nicht unterscheiden. Behandeln Sie das also als Obergrenze für eigenen Code in öffentlichen Apps, nicht als bestätigte Zahl.

So oder so: Wenn Sie die Planung aufschieben, weil Sie Angst davor haben, was Ihre Entwickler 2018 gebaut haben, dann sprechen die Zahlen dafür, dass Sie dieses Problem nicht haben. Prüfen statt annehmen, denn wenn eigener Code existiert, dominiert er alles andere am Projekt. Aber er ist wirklich selten.

Befund 5: Externe Integrationen sind die eigentliche versteckte Abhängigkeit

Das ist der Punkt, der uns überrascht hat. 4.101 Anwendungen, 27,4 Prozent, erlauben mindestens eine externe Domain.

Das heißt, mehr als ein Viertel dieser Anwendungen spricht mit etwas außerhalb von ArcGIS. Ein anderes System, der Dienst einer anderen Behörde, ein eigener Endpunkt, den vor Jahren jemand aufgesetzt hat. Bei Anwendungen mit echtem Traffic ist es ein Drittel.

Das ist deutlich über tausendmal häufiger als eigene Widgets, und wir haben es nirgends diskutiert gesehen. Es ist außerdem schwerer zu planen, weil die Abhängigkeit nicht Ihnen gehört: Sie gehört einem anderen Team, einem anderen Dienstleister oder einer anderen Organisation, jeweils mit eigenem Zeitplan und eigener Meinung dazu, ob sie etwas ändern möchte.

Wenn Sie vor der Migrationsplanung eine Sache erfassen, dann diese.

Befund 6: Bearbeitung ist in öffentlichen Apps selten, und das zeigt, wo die Kosten liegen

Nur 1.099 Anwendungen, 7,3 Prozent, enthalten ein Bearbeitungs-Widget.

Das liegt nicht daran, dass Organisationen keine Daten über Web AppBuilder bearbeiten. Es liegt daran, dass Bearbeitung eine Anmeldung erfordert, diese Anwendungen also nicht öffentlich sind und wir sie nicht sehen können.

Das ist die wichtigste Einschränkung dieser Studie, und wir wollen dabei deutlich sein. Alles oben beschreibt die öffentliche Hälfte der Welt: Planungsregister, Hochwasserkarten, Flurstücksviewer, Wertstoffhöfe. Die Anwendungen, die wirklich teuer zu migrieren sind, jene mit Bearbeitungsprozessen, geschützten Diensten, Single Sign-on und eigenen Integrationen, liegen hinter einer Anmeldung.

Die Erweiterung hat das verschärft statt entschärft. Über drei getrennte Durchläufe hinweg, die tausende Kandidaten-Organisationen abgedeckt haben, hat unsere Methode praktisch keine selbst gehosteten ArcGIS Enterprise Portale gefunden. Enterprise Portale stehen nicht im Index von ArcGIS Online, eine öffentliche Suche erreicht sie also nicht: Die einzigen zwei in diesem Datensatz sind enthalten, weil wir ihre Hostnamen bereits kannten. Da sich Bearbeitung, Single Sign-on und geschützte Dienste genau dort konzentrieren, ist der teuer zu migrierende Teil der Welt genau der Teil, für den diese Methode strukturell blind ist.

Wenn Sie das hier lesen und Ihre Migration überschaubar finden, prüfen Sie das also bitte zuerst gegen Ihren eigenen internen Bestand. Die öffentlichen Apps sind konstruktionsbedingt die einfache Hälfte.

Was wir daraus mitnehmen würden

1. Erfassen Sie externe Integrationen zuerst. Mehr als ein Viertel der Apps hat eine, bei Apps in echter Nutzung ein Drittel, sie sind die Abhängigkeit, die Sie nicht kontrollieren, und sie haben die längste Vorlaufzeit.
2. Kalkulieren Sie nicht pro Anwendung. Knapp die Hälfte dieser Apps hat drei Layer oder weniger, eine hat 491. Ein Pauschalpreis pro App verlangt für die einfachen zu viel und unterschätzt die Ungeheuer deutlich.
3. Prüfen Sie das Verhalten der Attributtabelle früh mit echten Anwendern. Sie steckt in 88 Prozent der Apps und hat die substanziellste dokumentierte Lücke. Sie ist die wahrscheinlichste Quelle für "das ging vorher" nach dem Go-live.
4. Nehmen Sie eigene Widgets nicht an. Bestätigen Sie es. Die Wahrscheinlichkeit spricht klar für Sie, und es verändert den gesamten Plan.
5. Zählen Sie Ihre nicht öffentlichen Apps. Jede Zahl, die aus öffentlichen Anwendungen abgeleitet ist, auch jede Zahl in diesem Artikel, ist eine Untergrenze.

Einschränkungen

Klar benannt, denn Forschung ohne Einschränkungen ist Marketing:

• Nur öffentliche Anwendungen. Was nicht öffentlich geteilt ist, ist hier unsichtbar. Wie oben verzerrt das den Datensatz in Richtung einfacherer Apps, und deshalb sollte die Bearbeitungszahl nicht als Bearbeitungsquote gelesen werden.
• Selbst gehostete Enterprise Portale fehlen strukturell. Sie stehen nicht im Index von ArcGIS Online. Zwei erscheinen hier nur, weil wir ihre Hostnamen direkt eingespeist haben. Das ist die größte Lücke im Datensatz.
• Sechs Länder, ungleich erfasst. Die US-Zahlen stammen aus einer zufälligen Stichprobe von 500 Organisationen mit festem Startwert, gezogen aus rund 2.700 gefundenen, weil eine vollständige Prüfung hunderttausende API-Aufrufe ohne statistischen Gewinn bedeutet hätte. Die Stichprobe ist zufällig und nicht nach Größe sortiert, was sie auf große, untypische Anwendungen verzerrt hätte. Großbritannien, Irland und der deutschsprachige Raum sind für öffentlich geteilte Apps, die wir finden konnten, nahezu vollständig.
• Die Suche hat die Regionen unterschiedlich erreicht. Deutschsprachige Anwendungen ließen sich vollständig aufzählen, weil diese Abfrage unter das Ergebnislimit der API fällt. Englischsprachige überschreiten es und mussten nach Aktualität und Nutzung abgetastet werden. Wir vergleichen Regionen daher nur auf Anwendungsebene und nur dort, wo der Unterschied auch bei Beschränkung auf echten Traffic bestehen bleibt.
• Wir haben höchstens 100 Anwendungen pro Organisation erfasst. 31 Organisationen haben dieses Limit erreicht, ihre echten Bestände sind also größer und der Datensatz unterzählt das Gesamtvolumen. Aus demselben Grund veröffentlichen wir keine Zahl zum größten Bestand, denn sie wäre ein Artefakt unseres eigenen Limits.
• 14.978 Konfigurationen aus 15.715 gefundenen Anwendungen ausgelesen. Die übrigen 737 ließen sich anonym nicht laden, was selbst mild informativ ist.
• Eine Momentaufnahme aus Juli 2026. Esri schließt die Experience Builder Lücken aktiv, die Tabelle oben wird sich also verbessern. Prüfen Sie sie gegen Esris Matrix, statt dieser Tabelle später zu vertrauen.
• Widget-Namen sind ein unvollkommener Näherungswert für das, was ein Widget tut, und können eigenen Code in keine Richtung beweisen. Das haben wir schon einmal falsch gemacht, siehe Befund 4.

Korrekturen

Dieser Artikel wurde zweimal korrigiert, und wir zeigen das lieber, als es zu verbergen:

• Anzahl eigener Widgets. Vorher "9 Anwendungen, 0,4 Prozent". Unsere Liste der Standard-Widgets ließ die 3D-Szenen-Widgets von Web AppBuilder aus, wodurch drei Standard-Widgets als Kandidaten für eigenen Code gezählt wurden. Jetzt 3 von 14.978 Anwendungen, alle in Befund 4 benannt.
• Bearbeitungs-Widgets. Eine frühe Fassung auf Basis einer Stichprobe von 117 Apps nannte 1 Prozent und keine nicht standardmäßigen Widgets. Beides war für diese Stichprobengröße zu absolut.

Wie Sie das nachvollziehen

Jede Zahl stammt aus Esris öffentlicher API. Die Abfragen sind type:"Web Mapping Application" AND typekeywords:"Web AppBuilder" gegen sharing/rest/search, dann sharing/rest/content/items/{id}/data für jede Konfiguration. Das Feld culture: ist durchsuchbar und der praktische Weg zu nicht englischsprachigen Anwendungen. Wenn Sie die Zahlen für Ihre eigene Organisation wollen, sind das zwei API-Aufrufe und etwas Zählen.

Wenn Sie das lieber nicht selbst machen: Unser fünftägiger Modernisierungs-Blueprint erledigt es sauber, inklusive der nicht öffentlichen Anwendungen, die diese Studie nicht sehen kann.

Quellen

• Individual widget functionality matrix between Web AppBuilder and Experience Builder, Esri Community
• Experience Builder for Web AppBuilder users, Esri Dokumentation
• ArcGIS Web AppBuilder retirement, Esri Dokumentation
• ArcGIS Web AppBuilder widget overview, Esri Dokumentation, genutzt als Referenzliste der Standard-2D-Widgets
• ArcGIS Web AppBuilder 3D widget overview, Esri Dokumentation, der 3D-Satz, den wir ursprünglich ausgelassen hatten

Mapular ist Esri Partner mit der Nonprofit Specialty. Gemeinsam mit Esri Deutschland haben wir den UNESCO World Heritage Site Navigator auf ArcGIS Experience Builder, Dashboards und Notebooks gebaut, zur Überwachung von mehr als 1.000 eingetragenen Welterbestätten. Wenn Sie einen Fehler in diesen Daten finden, möchten wir das wirklich wissen: hello@mapular.com.