App modernisieren oder neu bauen? Fünf Prüfpunkte

„Können wir die App retten oder müssen wir neu anfangen?” Diese Frage kommt bei uns meistens, nachdem etwas schiefgegangen ist: ein Release ist gescheitert, ein Dienstleister hat aufgehört, oder die Bewertungen sind gekippt.

Beide vorschnellen Antworten sind teuer. Wer eine tragfähige App wegwirft, zahlt für Arbeit, die schon getan war — inklusive aller Sonderfälle, die über Jahre eingebaut wurden und die niemand mehr im Kopf hat. Wer eine nicht mehr tragfähige App am Leben hält, zahlt jedes Jahr ein bisschen mehr für immer weniger Fortschritt.

Die Entscheidung hängt an fünf Fragen: Lebt die Basistechnologie noch? Lässt sich die App überhaupt bauen? Trägt das Datenmodell das heutige Geschäft? Gibt es noch jemanden, der sie versteht? Und was genau ist eigentlich kaputt? Alles davor ist Bauchgefühl.

Der Reflex, der in beide Richtungen falsch ist

Entwickler neigen zum Neubau. Das hat einen nachvollziehbaren Grund: Fremden Code zu verstehen ist mühsamer, als eigenen zu schreiben. Ein Neubau fühlt sich schneller an, weil man beim Schätzen nur an das denkt, was man kennt — und nicht an die vierzig Sonderfälle, die in der alten App stecken, weil ein Kunde sie vor drei Jahren gebraucht hat.

Auftraggeber neigen zum Erhalt. Auch nachvollziehbar: Die App ist bezahlt, sie funktioniert doch irgendwie, und ein Neubau klingt nach einem Budget, das nicht eingeplant war.

Beide Reflexe sind Gefühl, keine Analyse. Wir sehen uns deshalb fünf Punkte an, bevor wir eine Empfehlung geben.

Die fünf Prüfpunkte

1. Lebt die Basistechnologie noch?

Die erste Frage ist die härteste, weil sie oft schon entscheidet. Wird das Framework, auf dem die App steht, noch gepflegt? Gibt es Sicherheitsupdates? Lässt sich damit noch gegen aktuelle Store-Anforderungen bauen?

Wenn die Antwort nein ist, ist die Diskussion vorbei. Eine App auf einer eingestellten Technologie kann man noch eine Weile betreiben, aber nicht mehr weiterentwickeln — und der Zeitpunkt, an dem sie aus dem Store fliegt, ist absehbar.

Ein Zwischenfall, den wir öfter sehen: Die Technologie lebt, aber die konkrete Version ist so alt, dass der Weg zurück in die Gegenwart über mehrere Hauptversionen führt. Das ist dann keine Frage von Ja oder Nein, sondern von Aufwand — und der lässt sich abschätzen.

2. Lässt sich die App überhaupt bauen?

Klingt banal, ist es nicht. Wir übernehmen regelmäßig Projekte, bei denen niemand mehr sagen kann, ob sich aus dem vorliegenden Stand ein Release erzeugen lässt. Fehlende Schlüssel, eine Entwicklungsumgebung, die es so nicht mehr gibt, Abhängigkeiten, die von einem Server geladen wurden, den es nicht mehr gibt.

Das ist der erste praktische Test: einen Build erzeugen, ohne etwas zu ändern. Gelingt das in wenigen Stunden, ist die Lage besser als befürchtet. Braucht es Tage, ist das ein Befund über den Zustand des gesamten Projekts.

3. Trägt das Datenmodell noch das Geschäft?

Oberflächen lassen sich austauschen. Das Datenmodell darunter nicht so leicht — es steckt in der Datenbank, in den Schnittstellen, in den gespeicherten Daten der Nutzer.

Wenn das Modell noch zu dem passt, was das Unternehmen heute tut, ist eine Sanierung realistisch: neue Oberfläche, aufgeräumte Architektur, gleiche Daten. Wenn das Geschäft sich weiterentwickelt hat und das Modell nur mit Zusatzfeldern und Sonderfällen hinterhergeschleppt wurde, wird jede Änderung teurer als sie sein müsste. Dann ist der Neubau ehrlicher.

4. Gibt es jemanden, der die App versteht?

Wissen ist ein Projektwert, der nirgends bilanziert wird. Wenn die Leute, die die App gebaut haben, noch erreichbar sind und es Dokumentation gibt, ist eine Sanierung erheblich günstiger.

Ist das Wissen weg, kommt vor jeder Änderung eine Rekonstruktionsphase. Die ist machbar — wir machen sie regelmäßig — aber sie kostet, und sie muss in die Rechnung.

5. Was ist wirklich kaputt?

Der wichtigste und am häufigsten übersprungene Punkt. „Die App ist schlecht” ist keine Diagnose. Häufig steckt dahinter eines von drei sehr unterschiedlichen Problemen:

• Sie sieht alt aus. Das ist ein Oberflächenthema und meistens der günstigste Fall.
• Sie ist instabil. Das kann an einer Stelle liegen oder überall — der Unterschied ist erheblich.
• Sie kann nicht, was heute gebraucht wird. Das ist eine Produktfrage, keine technische.

Diese drei Fälle führen zu völlig verschiedenen Empfehlungen. Sie zu unterscheiden ist der eigentliche Zweck einer Bestandsaufnahme.

Der dritte Weg, der selten vorgeschlagen wird

Zwischen Sanierung und Neubau liegt eine Möglichkeit, die in Angeboten kaum vorkommt: schrittweise ersetzen.

Die App bleibt im Store, wird aber von innen erneuert — ein Bereich nach dem anderen, jeder einzeln ausgeliefert. Das dauert länger als ein Neubau am Stück und ist in der Summe nicht billiger. Es hat aber zwei Vorteile, die je nach Lage entscheidend sind: Es gibt keine Phase, in der zwei Apps parallel gepflegt werden müssen, und die Nutzer merken vom Umbau nichts außer, dass es besser wird.

Bei einer Zyklus-App haben wir genau so gearbeitet: migriert statt neu gestartet, mit dem Anspruch, dass keine Anwenderin dabei Daten oder gekaufte Lizenzen verliert. Das war der aufwendigste Teil des Projekts — und der unsichtbarste.

Die Kosten, die in beiden Angeboten fehlen

Angebote für Sanierung und Neubau vergleichen sich schlecht, weil sie unterschiedliche Dinge verschweigen.

Beim Neubau fehlt meistens der Altbestand. Eine bestehende App enthält Jahre von Sonderfällen: der Kunde mit der abweichenden Rechnungsstellung, das Gerät mit der alten Firmware, der Ablauf, den die Buchhaltung so und nicht anders braucht. Diese Fälle stehen in keinem Konzept, weil niemand sie mehr aufzählen kann — sie tauchen erst auf, wenn die neue App live geht und jemand sagt: „Aber früher konnte man…”

Unsere Erfahrung: Die Anforderungsaufnahme für einen Neubau ist zu einem guten Teil Archäologie an der alten App. Wer diesen Posten im Angebot nicht sieht, sieht ihn später in der Nachtragsrechnung.

Bei der Sanierung fehlt oft der Endzustand. „Wir modernisieren die App” ohne Zielbild führt dazu, dass nach dem Budget dieselbe App dasteht, nur etwas neuer. Eine Sanierung braucht dieselbe Klarheit über das Ergebnis wie ein Neubau — sonst wird sie zu Wartung mit größerem Etat.

Die Migration ist der Teil, den niemand sieht

Egal welchen Weg man wählt: Wenn es die App schon gibt, gibt es Nutzer mit Daten. Und die dürfen nichts verlieren.

Das klingt selbstverständlich und ist der aufwendigste Einzelposten in solchen Projekten. Bestandsdaten müssen in die neue Struktur, gekaufte Lizenzen müssen gültig bleiben, angefangene Vorgänge dürfen nicht verschwinden. Bei einer App mit Abo-Modell heißt das, dass die Zahlungshistorie mitwandert — sonst steht ein zahlender Kunde plötzlich vor einer Bezahlschranke.

Der Test dafür ist unbequem, aber eindeutig: Kann eine Nutzerin die neue Version installieren, ohne etwas zu merken außer, dass es besser aussieht? Wenn ja, war die Migration gut. Wenn sie sich neu anmelden, neu kaufen oder Daten neu eingeben muss, war sie es nicht.

Was wir vor einer Empfehlung tun

Wir schauen uns die App von außen an, bevor wir über Code reden: unterstützte Betriebssystemversionen, Update-Kadenz, Abstürze, was in den Bewertungen steht, wie der Store-Auftritt dasteht. Das meiste davon ist öffentlich einsehbar und sagt schon viel.

Erst danach lohnt der Blick in den Code — und auch da geht es zuerst um wenige Fragen: Lässt sich bauen, gibt es Tests, wie ist die Architektur geschnitten, wie alt sind die Abhängigkeiten.

Das Ergebnis ist in beide Richtungen offen. Wir haben Kunden schon vom Neubau abgeraten, weil die vorhandene App besser war als ihr Ruf, und wir haben von Sanierungen abgeraten, bei denen jeder investierte Euro in einen Zustand geflossen wäre, der in zwei Jahren wieder zur Debatte steht.

---

Passend dazu: Was bei einer App-Modernisierung konkret passiert, steht auf der Leistungsseite. Wenn die App danach in Betreuung soll: App-Pflege.