Foto: Google Gemini · AI-generated
Jeder Softwarehersteller hat so eine Liste. Das Framework, das zwei Hauptversionen zurückliegt. Das Modul, das niemand gern öffnet. Die Plattform, die modern war, als man sie gewählt hat.
Blockiert wird diese Liste selten von der Technik. Die meisten Teams wissen genau, was zu tun wäre. Sie finden nur kein Zeitfenster dafür.
Und genau das unterscheidet Modernisierung bei einem Produktunternehmen von Modernisierung an einem eigenen internen System.
Über das Upgrade entscheiden Sie nicht
Wer eine interne Anwendung modernisiert, kann die Migration planen. Eine Organisation, eine Entscheidung, ein Wochenende.
Ein Softwarehersteller kann das nicht. Ihre Software läuft in fremden Betrieben. Dort wird aktualisiert, wenn es dort passt, auf Hardware, die Sie nicht ausgesucht haben, angebunden an Systeme, die Sie nie gesehen haben. Womöglich sitzen Kunden drei Versionen zurück und fühlen sich dort ausgesprochen wohl.
“Wir haben es neu gebaut” ist deshalb kein abgeschlossenes Projekt. Es ist der Beginn einer Migration, die Sie für jeden Kunden einzeln fahren, in dessen Takt — während Sie die alte Version für alle weiterpflegen, die noch nicht gewechselt sind. Die Entwicklung ist die günstigere Hälfte.
Deshalb kostet Modernisierung meist ungefähr das Doppelte der Schätzung. Die Schätzung deckt den Bau des Neuen ab. Selten deckt sie ab, anderthalb Jahre lang zwei Dinge parallel zu betreiben.
Die Frist kommt meistens von außen
Weil sich die interne Begründung für Modernisierung schwer gewinnen lässt, passiert das meiste davon erst, wenn etwas von außen dazu zwingt.
Windows CE ist dafür das deutlichste Beispiel der letzten Jahre. Eine ganze Generation von Handhelds für Lager und Produktion lief darauf. Als die Plattform das Ende ihres Lebenszyklus erreichte, erbte jeder Hersteller mit einer App darauf eine Frist, die er sich nicht ausgesucht hatte.
Genau diese Migration haben wir für einen Softwarehersteller gemacht, dessen Lager-App — ein Add-on für Sage 100 — dort festhing. Mobile ERP hat sie von Windows CE auf natives Android gebracht, ausgeliefert als White-Label unter der Marke des Herstellers.
Die interessante Randbedingung war nicht Android. Sie war, dass die App weiterhin exakt so mit Sage 100 sprechen musste wie zuvor — damit die Kunden ihre Hardware tauschen konnten, ohne irgendetwas daran zu ändern, wie die App in ihrem Betrieb steckt. Bestand, Wareneingang, Versand, Produktion: dieselben Abläufe, neue Plattform.
Die Hülle modernisieren, den Vertrag halten
Diese Randbedingung ist die eigentliche Lehre.
Die Teile Ihres Produkts, von denen Ihre Kunden wirklich abhängen, sind meist nicht die Teile, die Sie ersetzen wollen. Abhängig sind sie von Verhalten, Datenformaten und Schnittstellen. Was den Bildschirm zeichnet, ist ihnen selten wichtig.
Die Modernisierungen, die gelingen, verschieben deshalb eher die Grenze als das Ganze: Plattform, Oberfläche und Laufzeitumgebung austauschen — und den Schnittstellenvertrag stillhalten. Das ist weniger befriedigend als ein sauberer Neubau. Es ist aber die Variante, die ausgeliefert wird, weil sie nicht von allen Kunden gleichzeitig eine Änderung verlangt.
Mit der Auslieferung endet die Pflege nicht
Produktunternehmen tragen noch etwas, das interne Teams oft nicht haben: Verpflichtungen gegenüber Standards, die jemand anderem gehören.
Wir haben ein Werkzeug gebaut und gepflegt, das Lexware und die D!VE-Plattform der Deutschen Telekom verbindet und Auftrags- und Angebotsdaten in genau das XML überführt, das die Beschaffungsschnittstelle der Telekom akzeptiert. Der Bau war endlich. Die Verpflichtung nicht — das Format der Telekom entwickelte sich weiter, und das Werkzeug musste mitziehen, sonst konnte der Partner schlicht keine Angebote mehr einreichen.
Jeder Hersteller, der an die Plattform eines großen Partners, an ein behördliches Schema oder an ein Zahlungsverfahren angebunden ist, hat irgendwo diese Form. Das ist keine technische Schuld. Das ist eine laufende Zusage, und sie verdient eine eigene Zeile im Plan, statt in “Wartung” zu verschwinden.
Ohne die Roadmap einzufrieren
Die praktische Antwort ist unspektakulär: Modernisierung braucht ein eigenes, parallel laufendes Gleis mit eigener Kapazität — kein Quartal, in dem Funktionen pausieren.
Roadmaps überleben es nicht, angehalten zu werden. Der Wettbewerb liefert weiter, und der Vertrieb verkauft weiter dagegen. Eine Modernisierung, für die das Produkt stillstehen muss, wird meist auf halbem Weg abgebrochen — und das ist das schlechteste Ergebnis: halb migriert, zwei Codebasen, noch kein Nutzen.
Das ist einer der häufigeren Gründe, warum Hersteller ein externes Team dazunehmen. Nicht, weil die Arbeit sie überfordert, sondern weil sie neben der Roadmap laufen muss statt an ihrer Stelle. So ist der Großteil unserer App-Modernisierung für Softwarehersteller geschnitten.
Wenn Sie so eine Liste mit sich tragen, sprechen wir darüber.