In fast jedem polnischen Unternehmen mit 15 Jahren auf dem Buckel steht irgendeine Anwendung, vor der alle ein bisschen Respekt haben. Der Cousin des Inhabers hat sie 2011 in Access geschrieben. Oder ein externer Freelancer hat sie 2014 in WinForms gebaut. Oder „dieser Praktikant damals". Sie läuft. Sie hält den Laden am Leben. Und schon seit Langem dauert das Drumherumarbeiten länger als die eigentliche Arbeit in ihr.
Dieser Text geht um eine Entscheidung, die die meisten KMU rund fünf Jahre zu lang aufschieben: was tun wir mit dieser Anwendung. Jeder der drei Wege — warten, von Grund auf neu schreiben, durch Standard-SaaS ersetzen — hat einen Moment, in dem er richtig ist, und einen, in dem er ein Fehler ist.
Anzeichen, dass die alte App teuer wird
Niemand wacht morgens auf und denkt „heute schreiben wir unser Lagersystem neu". Der Moment kommt leise, in Form einer Reihe kleiner Symptome. Wenn du drei davon bei dir wiedererkennst — das Thema ist real.
- Die App läuft nur auf einem bestimmten Computer im Büro (meistens einem alten), weil „sie auf den anderen nicht startet".
- Nach jedem Windows-Update geht etwas kaputt — der Druck, der PDF-Export, die Datenbankverbindung.
- Niemand weiß mehr, wo der komplette Quellcode liegt. Es gibt zwei ZIP-Archive mit verschiedenen Daten und keiner kann sagen, welches aktuell ist.
- Mitarbeitende im Außendienst können sie nicht nutzen, weil sie RDP ins Büro braucht oder ein VPN, das die halbe Belegschaft mit „dem Ding, das nachmittags nicht geht" verbindet.
- Jede kleine Änderung — ein neues Druckformular, ein zusätzliches Feld, ein anderer Auftragsstatus — kostet 30 Stunden externer Arbeit, weil niemand mehr weiß, wie das gebaut wurde.
- Eine neu eingestellte Person braucht zwei Tage, bis die App auf ihrem Laptop überhaupt läuft.
Wenn du eine einfache Änderung aufschiebst, weil „Maciek gesagt hat, das fasst man nicht an" — dann ist genau jetzt der Moment. Die App dient dir nicht mehr, sie diktiert dir, was du tun darfst.
Drei Wege: warten, neu schreiben, migrieren
In der KMU-Realität gibt es genau drei vernünftige Antworten. Eine vierte gibt es nicht, auch wenn Berater manchmal Hybride verkaufen wollen.
- Warten und kontrolliert refaktorieren. Die App bleibt, wird aber an den aktuellen Stack angeschlossen, bekommt Tests, eine Dokumentation und die 2-3 nervigsten Bugs werden behoben.
- Von Grund auf neu schreiben. Wir werfen den alten Code weg und schreiben eine neue Anwendung, die das Gleiche tut, aber auf einem modernen Stack (z. B. .NET 8 + SQL Server + Browser).
- Durch Standard-SaaS ersetzen. Wir geben die eigene Software auf, kaufen ein fertiges Produkt von der Stange und migrieren Daten und Prozess dorthin.
Jeder Weg kostet anders und bringt etwas anderes. Die Wahl ist keine Geschmacksfrage — es ist eine Frage davon, wie stark sich dein Prozess vom Markt unterscheidet und wie sehr die App tatsächlich dein Wettbewerbsvorteil ist.
Wann Warten und ein leichter Refactor sinnvoll sind
Kurz: wenn die App läuft, relativ einfach ist und sich in Zukunft wahrscheinlich kaum ändern muss. Typischer Fall: ein kleines Access-Register mit zwei Tabellen und drei Formularen, das zwei Personen in der Buchhaltung nutzen. Das auf .NET neu zu schreiben wäre Overkill.
Refactor ergibt Sinn, wenn:
- Die App klein ist (ein gutes Dutzend Bildschirme, eine einfache Datenbank) und der unterstützte Prozess stabil ist und du ihn nicht ändern willst.
- Du Zugang zum Quellcode hast und mindestens eine Person, die diese Technologie versteht.
- Die Kosten eines Rewrites das Wartungsbudget für 3-4 Jahre übersteigen.
- Es für deine Nische noch keine vernünftige SaaS-Alternative gibt.
In dieser Variante investierst du einmal in eine ordentliche Aufräumaktion: Versionskontrolle in Git, eine Test-Datenbankkopie, eine priorisierte Liste bekannter Fehler, ein bis zwei Korrekturen, die am meisten wehtun. Aufwand: typisch 60-150 Stunden. Ergebnis: Ruhe für die nächsten 2-3 Jahre.
Wann sich ein Neuschreiben lohnt
Typischer Fall: die App ist der operative Kern des Unternehmens und unterscheidet dich von Wettbewerbern — weil sie etwas tut, das kein Standardsystem so macht wie du. Beispiele: ein eigener Produktkonfigurator in der Metallverarbeitung, ein hauseigenes Provisionsabrechnungssystem für den Vertrieb, ein Tourenplanungstool für die Kontraktlogistik.
Ein Rewrite ergibt Sinn, wenn:
- Die App wirklich einen Prozess unterstützt, der dein Vorteil ist — und du den nicht auf jemandes SaaS standardisieren willst.
- Der Stack so alt ist, dass die jährliche Wartung mehr kostet als die abgeschriebene Investition in einen Rewrite über 3 Jahre.
- Dinge fehlen, die heute Basis sind (Homeoffice, mobile Nutzung, API-Integration mit der Buchhaltung, KSeF-Export).
- Du auf Bus-Faktor 1 sitzt — eine Person kennt den Code, geht oder wird krank, und du bleibst mit einer .mdb-Datei und einem Post-it zurück.
Bei einem unserer Kunden — einer 24-köpfigen Verpackungsfabrik in der Nähe von Konin — lief seit 2013 ein Produktionsplanungssystem, das ein ehemaliger Mitarbeiter in Access geschrieben hatte. Die App lief auf einem ganz bestimmten Computer in der Halle, weil „nur dort hat sie gestartet". Schichtleiter konnten sie nicht vom eigenen Laptop nutzen, Planer mussten zu diesem einen Arbeitsplatz laufen, und zweimal pro Woche hängte sich die App auf und die letzten 20-30 Minuten Arbeit waren weg. Nach einem 6-Wochen-Projekt (~220 Arbeitsstunden, Kosten ca. 65 000 zł) haben wir sie auf .NET 8 mit SQL-Server-Backend und Browser-Oberfläche neu geschrieben. Nach dem Rollout: Zugriff von jedem Arbeitsplatz und von zu Hause aus, Integration mit Comarch Optima statt manueller Übertragung von Aufträgen, die Zeit zur Erstellung eines Schichtplans sank von rund 35 auf 8 Minuten. In den ersten drei Monaten gewann das Unternehmen etwa 18 Planer-Stunden pro Woche zurück.
Wann eine Migration zu SaaS sinnvoll ist
Typischer Fall: dein Prozess unterscheidet sich kaum vom Rest des Marktes, und jemand hat bereits ein fertiges Produkt dafür gebaut — oft besser als das, was ein kleiner Auftragsentwickler liefern würde. CRM, Helpdesk, ein einfaches WMS für E-Commerce, einfache Projektverwaltung. Hier eigene Software zu bauen heißt meistens, an etwas zu feilen, das ein Standardanbieter im nächsten Monat überholt.
Migration ergibt Sinn, wenn:
- Du das Gleiche tust wie tausend andere Firmen in deiner Branche — Reisekosten abrechnen, Urlaube verwalten, einfache Serviceangebote schreiben.
- Ein Standardprodukt 85 % deines Prozesses abdeckt und du bereit bist, die fehlenden 15 % an das Tool anzupassen statt umgekehrt.
- Deine Teams klein sind (bis zu 30 Personen), sodass SaaS-Lizenzkosten deutlich niedriger sind als die Wartung eigenen Codes.
- Regelmäßige Funktionserweiterungen (die der Anbieter monatlich liefert) dir wichtiger sind als vollständige Kontrolle.
Denk daran: eine SaaS-Migration ist nicht „kostenlos", nur weil du keinen Code schreibst. Der Aufwand ist ein Datenmigrationsprojekt, Prozesszuordnung, Schulung — und immer ein paar Dinge, die anders gedacht werden müssen als bisher.
Wie man das Projekt anpackt, ohne unterzugehen
Egal welchen Weg du wählst, der häufigste Fehler polnischer KMU ist, aus der Modernisierung „ein großes Jahresprojekt" zu machen. Das ist der sicherste Weg, dass nach einem halben Jahr niemand mehr weiß, warum wir angefangen haben.
Was stattdessen funktioniert:
- Beginn mit einem konkreten Schmerz. Nicht „wir schreiben die App neu", sondern „in 6 Wochen erstellen die Planer den Schichtplan von zu Hause". Der Rest kann warten.
- Schneide es in 4-6-Wochen-Häppchen, in jedem lieferst du eine nutzbare Sache. Das schlimmste Projekt ist eines, das nach 4 Monaten noch nichts produziert hat.
- Alte und neue App müssen ein paar Wochen nebeneinander laufen können. Ein „Big-Bang"-Cutover am Freitagabend funktioniert im KMU fast nie — es fehlen am Montag die Hände zum Löschen.
- Historische Daten bewusst migrieren. Nicht alle. Wähle, was du operativ wirklich brauchst (meistens 2-3 Jahre rückwärts), den Rest lass schreibgeschützt im alten System.
Wie geht es weiter
Wenn es in deiner Firma eine Anwendung gibt, deren Namen du aus Angst nicht laut aussprichst — das ist ein gutes Zeichen, dass es Zeit ist, sie sich anzuschauen. Die Entscheidung „warten, neu schreiben oder migrieren" fällt nicht auf Folien. Sie fällt nach einem einstündigen Gespräch, in dem jemand von außen den Prozess von innen ansieht und offen sagt, wo Vernunft endet und Sentimentalität für zehn Jahre alten Code beginnt.
Solche Gespräche führen wir regelmäßig für polnische KMU. Das erste ist kostenlos und dauert eine halbe Stunde.
Eine alte App, die niemand anfassen darf, ist kein Wettbewerbsvorteil. Sie ist Schuld, deren Zinsen jedes Quartal wachsen.