Suchen Sie, wie lange eine Web AppBuilder Migration dauert, und Sie finden nichts Brauchbares. Esri veröffentlicht es nicht, weil sie die Arbeit nicht so verkaufen. Anbieter von Migrationswerkzeugen veröffentlichen es nicht, weil ihre Antwort "kaufen Sie das Werkzeug" lautet. Beratungen veröffentlichen es nicht, weil sie es lieber im Gespräch abschätzen.
Wir sind eine Beratung, betrachten Sie das also als interessiert. Aber das Schweigen ist unbrauchbar genug, dass eine gerade Antwort mehr wert ist als der Verhandlungsvorteil, sie zurückzuhalten.
Wir nennen Ihnen keine Stundenzahl. Wer Ihnen eine nennt, ohne Ihren Bestand gesehen zu haben, rät. Die ehrliche Fassung dieses Artikels ist eine Aufschlüsselung dessen, was die Zahl tatsächlich treibt. Wo wir echte Häufigkeitsdaten anhängen können, haben wir es getan, aus unserer Studie zu 14.978 Web AppBuilder Anwendungen.
Die zwei Preise, die es schon gibt
Es gibt zwei öffentliche Anker, und sie liegen drei Größenordnungen auseinander.
Automatisierte Konverter pro Anwendung, etwa 25 USD pro App. Werkzeuge wie Geovonic Migrate und Cartinuum Web AppBuilder Migrate nehmen eine Anwendung und erzeugen ein Experience Builder Äquivalent. Zu diesem Preis lohnt ein Versuch offensichtlich.
Beratungsprojekte, im vierstelligen Bereich. Unser eigener Modernisierungs-Blueprint kostet 4.900 EUR für bis zu drei Anwendungen, und das ist Bewertung und Planung, nicht der Neubau.
Das sind keine konkurrierenden Angebote, und wer sie als konkurrierend darstellt, verkauft Ihnen etwas. Ein Konverter verschiebt ein Layout. Er kann Ihnen nicht sagen, welche Anwendungen stillzulegen sind, sieht Ihre geschützten Dienste nicht, migriert keinen eigenen Code und entscheidet nichts. Wenn Ihr Bestand wirklich aus zwölf einfachen öffentlichen Viewern besteht, ist der Konverter vielleicht das meiste, was Sie brauchen. Probieren Sie ihn zuerst. Uns wäre das lieber.
Was die Kosten tatsächlich treibt
Sortiert danach, wie häufig jeder Punkt in echten Anwendungen auftritt, denn die Häufigkeit bestimmt die Summe Ihres Bestands, nicht der schlimmste Fall.
1. Externe Integrationen, in 27,4 Prozent der Apps
Mehr als ein Viertel der Anwendungen erlaubt mindestens eine externe Domain, spricht also mit etwas außerhalb von ArcGIS.
Das ist der teuerste häufige Faktor und der am meisten übersehene, denn die Abhängigkeit gehört nicht Ihnen. Sie gehört einem anderen Team, einem anderen Dienstleister oder einer anderen Organisation. Jede muss identifiziert, gegen die Zielplattform getestet und häufig mit jemandem besprochen werden, der kein Interesse an Ihrem Stichtag und einen eigenen Release-Zyklus hat.
Der Aufwand liegt hier in der Abstimmung, nicht im Code. Das macht ihn am schwersten verdichtbar und am leichtesten unterschätzbar.
2. Verhalten der Attributtabelle, in 88,2 Prozent der Apps
Das am häufigsten genutzte Widget im Datensatz nach der Navigationsausstattung, und dasjenige mit der substanziellsten von Esri dokumentierten Lücke in Experience Builder: Es lässt sich nicht aus der Layerliste öffnen, und die Sichtbarkeit je Layer ist nicht so konfigurierbar wie in Web AppBuilder.
Für die meisten Anwendungen ist das eine kleine Anpassung plus ein Gespräch mit den Anwendern. Über einen Bestand von zwanzig Anwendungen sind das zwanzig kleine Anpassungen und zwanzig Gespräche, und genau dort verdoppelt sich die Schätzung unbemerkt.
3. Layer- und Popup-Konfiguration, Median 4 mit langem Ausläufer
Knapp die Hälfte der Anwendungen in unserem Datensatz hat drei operationale Layer oder weniger. 865 haben mehr als zwanzig. Eine hat 491.
Feldaliase, Sichtbarkeitsbereiche, Popup-Inhalte und Formatierung sind Konfiguration je Layer und wandern nicht mit dem Layer mit. Dieser Faktor skaliert also linear mit der Layer-Anzahl, was bedeutet, dass die Summe Ihres Bestands fast vollständig davon abhängt, wo Ihre Anwendungen in dieser Verteilung liegen. Zwei Organisationen mit je zehn Anwendungen können sich um den Faktor fünf unterscheiden.
4. Bearbeitungsprozesse, in 7,3 Prozent der öffentlichen Apps und intern in weit mehr
Selten in öffentlichen Anwendungen, weil Bearbeitung eine Anmeldung erfordert. Jede öffentliche Studie, auch unsere, untertreibt hier also. Wenn Sie Daten über Web AppBuilder bearbeiten, sind das Ihre teuren Anwendungen, und die Kosten liegen nicht im Widget: Sie liegen in Bearbeitungsvorlagen, Attributregeln, verknüpften Datensätzen, Rechten je Layer und dem Abnahmetest, der folgen muss.
Rechnen Sie damit, dass jede Anwendung mit Bearbeitung ein Mehrfaches des Aufwands eines reinen Viewers gleicher Größe bedeutet.
5. Print, in 26,0 Prozent der Apps
Hängt von einem Druckdienst und Layout-Vorlagen ab. Meist unkompliziert, gelegentlich eine Überraschung, wenn vor Jahren serverseitig eigene Vorlagen installiert wurden und sich niemand mehr daran erinnert.
6. Eigene Widgets, in 3 von 14.978 Apps
Zuletzt, und zwar absichtlich, weil dieser Punkt die Diskussion dominiert und fast nie auftritt. Drei Anwendungen von 14.978.
Wenn er auftritt, verändert er alles, denn eigener Code migriert nicht durch Konfiguration, und die Web AppBuilder Developer Edition wurde im Juli 2024 abgekündigt, gemeinsam mit der JavaScript-API-Version, gegen die sie entwickelt wurde. Die entscheidende Frage ist, ob der Quellcode noch existiert.
Planen Sie aber die 27,4 Prozent vor den drei von fünfzehntausend.
Warum ein Pauschalpreis pro Anwendung die falsche Form ist
Ein Pauschalpreis pro Anwendung ist attraktiv, weil er leicht vergleichbar ist. Für die meisten Bestände ist er außerdem in beide Richtungen gleichzeitig falsch.
Knapp die Hälfte dieser Anwendungen hat drei Layer oder weniger und eine Handvoll Standard-Widgets. Ein Pauschalpreis verlangt dafür zu viel, und ein Konverter erledigt sie wahrscheinlich.
Im Ausläufer liegt das Geld. Eine Anwendung mit 491 Layern, einem Bearbeitungsprozess und zwei externen Integrationen ist nicht das Fünffache eines einfachen Viewers, sie ist ein Projekt. Ein Pauschalpreis unterschätzt das deutlich, und ein unterkalkuliertes Projekt wird entsprechend geliefert.
Was ein Pauschalpreis pro Anwendung außerdem nicht kann, ist subtrahieren. Womit wir bei der günstigsten verfügbaren Einsparung sind.
Die günstigste Migration ist die, die Sie nicht machen
Zwei Schritte verkleinern einen Bestand, bevor jemand etwas neu baut:
Zusammenführung. Organisationen sammeln nahezu identische Viewer, die sich nur in Ausdehnung oder Layerauswahl unterscheiden, meist weil es einfacher war, eine App zu kopieren, als einen Filter zu ergänzen. Fünf in eine konfigurierbare Anwendung zu überführen ist günstiger als fünf neu zu bauen, und danach günstiger zu pflegen.
Stilllegung. Manche Anwendungen werden nicht genutzt. In unserem Datensatz liegen Anwendungen mit unter 200 Aufrufen insgesamt in Beständen neben Apps mit über einer Million. Esris eigene Item-Statistiken sagen Ihnen in etwa einer Minute, welche welche ist.
Wir haben separat darüber geschrieben, welche Anwendungen Sie nicht migrieren sollten. Es ist das kommerziell unbequemste, was wir veröffentlichen, und dasjenige, das am meisten Geld spart.
Was wir tatsächlich tun würden
- Zählen Sie die Anwendungen, auch die nicht öffentlichen. Öffentliche Zahlen sind eine Untergrenze.
- Sortieren Sie nach Nutzung. Esri veröffentlicht Aufrufzahlen pro Item. Alles mit vernachlässigbarer Nutzung ist ein Kandidat für Stilllegung, bevor es ein Kandidat für Migration ist.
- Finden Sie die Beinahe-Duplikate. Zusammenführen, bevor Sie neu bauen.
- Listen Sie jede externe Integration. Das hat die längste Vorlaufzeit und Sie kontrollieren es nicht.
- Trennen Sie Bearbeitung von reinem Lesen. Das sind unterschiedliche Projekte mit unterschiedlichem Testaufwand.
- Testen Sie einen Konverter an Ihrer einfachsten App. Für 25 USD ist das günstiger als ein Meeting darüber, ob man es testen sollte.
- Holen Sie einen Festpreis für das, was übrig bleibt, nachdem der Bestand geschrumpft ist.
Wenn die Schritte eins bis fünf nach Arbeit klingen, für die Sie keine Zeit haben, dann ist genau das unser fünftägiger Blueprint: 4.900 EUR, bis zu drei Anwendungen, endet in einem Festpreisangebot für die Umsetzung, und er deckt die nicht öffentlichen Anwendungen ab, die eine öffentliche Studie nicht sehen kann.
Und wenn die Antwort lautet, dass der größte Teil Ihres Bestands stillgelegt oder zusammengeführt werden sollte, dann sagen wir Ihnen das. Das ist im Regelfall der schnellste Weg, auf dem sich ein Blueprint bezahlt.
Häufigkeitsangaben stammen durchgehend aus unserer Studie zu 14.978 öffentlichen Web AppBuilder Anwendungen in 921 Organisationen in sechs Ländern, einschließlich der dort genannten Einschränkungen. Die Parity-Einschränkungen sind so dokumentiert, wie Esri sie in der Widget-Funktionsmatrix beschreibt.
