Alle Abbildungen in diesem Beitrag sind KI-generierte Symbolbilder. Sie zeigen keine realen Unternehmen, Systeme oder Mitarbeitenden.
Hinweis zur Einordnung: Dieser Beitrag erscheint im Unternehmensblog von H-Studio Berlin. Die Auswahlkriterien sind praktische Orientierung, keine Rangliste oder Rechtsberatung.
Kurze Antwort
Für eine Mittelstand-Modernisierung passt ein Partner, der zuerst Prozesse, Daten, Abhängigkeiten und Betriebsrisiken kartiert und erst danach über einen Rewrite entscheidet. Gute Anbieter können Alt- und Neusystem zeitweise parallel betreiben, Integrations- und Rückfallwege erklären, Fachanwender einbeziehen und Wissen an das interne Team übertragen. Ein pauschales „alles neu“ ist bei laufenden Kernprozessen meist kein belastbarer Startpunkt.
Legacy-Software ist nicht automatisch schlechte Software. Ein altes System kann geschäftskritisch, stabil und wirtschaftlich sein. Das Problem beginnt, wenn Änderungen unverhältnismäßig riskant werden, Wissen nur bei einzelnen Personen liegt, Daten mehrfach gepflegt werden oder Excel-Dateien einen Prozess tragen, den niemand mehr vollständig überblickt.
Die richtige Frage lautet daher nicht „Welcher moderne Stack ersetzt unser Altsystem?“, sondern: Welcher Teil des heutigen Betriebs begrenzt das Geschäft — und wie kann er ersetzt werden, ohne den restlichen Betrieb zu gefährden?
Auswahlkriterien für einen Modernisierungspartner
| Kriterium | Gute Arbeitsweise | Risikosignal |
|---|---|---|
| Systemverständnis | Prozesse, Daten, Nutzer und Abhängigkeiten werden vor Lösungsvorschlägen kartiert | Stack- und Rewrite-Empfehlung nach einem kurzen Sales-Call |
| Migrationsform | Big-Bang, schrittweise Ablösung und Stabilisierung werden gegeneinander geprüft | Vollständiger Rewrite gilt grundsätzlich als einzige saubere Lösung |
| Betriebsfortführung | Parallelbetrieb, Cutover, Rollback und Datenabgleich sind Teil des Plans | Betrieb wird erst für den finalen Go-live betrachtet |
| Integrationen | Quelle der Wahrheit, Schnittstellen und Fehlerfälle werden benannt | „SAP/DATEV/CRM anbinden“ bleibt eine einzelne Feature-Zeile |
| Fachbereich | Reale Nutzer und Ausnahmefälle fließen früh ein | Nur Management und IT definieren den künftigen Prozess |
| Datenmigration | Qualität, Historie, Mapping und Reconciliation werden getestet | Daten werden am Ende „einfach importiert“ |
| Mitbestimmung und Datenschutz | Monitoring- und Personaldatenfragen werden früh an zuständige Stellen gegeben | Rechtliche und organisatorische Fragen gelten als späteres Thema |
| Wissenstransfer | Dokumentation, Pairing und Handover sind laufende Deliverables | Nur der Anbieter kann das neue System betreiben |
| Wertnachweis | Jede Phase hat einen nutzbaren Prozess und messbare Abnahmekriterien | Fortschritt besteht aus technischen Meilensteinen ohne Fachnutzen |
Nicht jedes Legacy-System braucht einen Rewrite
Ein System sollte nicht ersetzt werden, nur weil Framework, Oberfläche oder Programmiersprache alt wirken. Modernisierung ist sinnvoll, wenn konkrete Grenzen bestehen:
- notwendige Änderungen sind kaum noch sicher auslieferbar;
- Sicherheitsupdates oder unterstützte Laufzeiten fehlen;
- geschäftskritisches Wissen liegt nur bei einzelnen Personen;
- Schnittstellen verhindern Automatisierung oder verursachen doppelte Datenpflege;
- Ausfälle, manuelle Korrekturen oder Lizenzkosten werden unverhältnismäßig;
- neue regulatorische oder vertragliche Anforderungen lassen sich nicht mehr abbilden;
- Fachbereiche bauen Schattenprozesse in Excel, E-Mail und lokalen Datenbanken.
Wenn das System stabil läuft und nur eine Oberfläche veraltet ist, kann ein gezielter Frontend-, Schnittstellen- oder Betriebsrefactor genügen. Wenn ein einzelner Report fehlt, ist ein vollständiges Plattformprogramm unverhältnismäßig. Ein guter Partner darf deshalb auch empfehlen, noch nicht zu modernisieren.
Strangler Fig statt Big-Bang: schrittweise ablösen
Der Strangler-Fig-Ansatz beschreibt die schrittweise Ablösung eines bestehenden Systems. Neue Funktionen oder abgegrenzte Domänen entstehen neben dem Altbestand. Verkehr, Daten oder Nutzer werden kontrolliert auf den neuen Pfad umgestellt, bis ein Teil des alten Systems nicht mehr benötigt wird.
Für ein mittelständisches Unternehmen kann das praktisch so aussehen:
- Ein neuer Auftragsstatus wird zunächst aus dem Altsystem gelesen und in einem modernen Dashboard sichtbar gemacht.
- Ein abgegrenzter Workflow — etwa Freigabe oder Dokumentenanforderung — wird im neuen System geführt.
- Schreibzugriffe werden über eine definierte Integrationsschicht koordiniert.
- Historische Daten werden nur soweit migriert, wie der neue Prozess sie benötigt.
- Nach fachlicher Abnahme wird der alte Teil deaktiviert; der restliche Legacy-Kern bleibt zunächst bestehen.
Der Ansatz ist kein automatisches Erfolgsrezept. Parallelbetrieb erzeugt eigene Komplexität: Daten können auseinanderlaufen, Zuständigkeiten müssen eindeutig sein und temporäre Integrationen dürfen nicht zum ewigen Provisorium werden. Der Vorteil ist ein anderer: Risiko und Lernen werden in kleinere Entscheidungen geteilt.
Ein Big-Bang kann trotzdem richtig sein, wenn das Altsystem klein, gut verstanden und sauber abtrennbar ist oder ein externer Anbieter den Betrieb kurzfristig beendet. Die Entscheidung sollte aus Systembeweisen folgen, nicht aus einem Architektur-Slogan.
Excel ersetzen — aber nur, wenn Excel wirklich das Problem ist
Excel ist ein starkes Werkzeug für Analyse, Planung und flexible Einzelfälle. Es wird zum Systemrisiko, wenn mehrere Personen gleichzeitig dieselben Geschäftsdaten verwalten, Versionen per E-Mail zirkulieren, Berechtigungen unklar sind oder ein kritischer Prozess von Makros und persönlichem Wissen abhängt.
Ein sinnvoller Ersatz beginnt nicht mit der Frage „Welche App bauen wir?“, sondern mit einer Prozessaufnahme:
- Welche Datei oder Tabelle ist die tatsächliche Quelle der Wahrheit?
- Wer darf Daten anlegen, ändern, freigeben oder exportieren?
- Welche Ausnahmen behandelt der Prozess?
- Welche Formeln bilden echte Geschäftsregeln ab?
- Welche Daten kommen aus CRM, ERP, DATEV oder anderen Systemen?
- Welche Ausgaben, Reports oder Übergaben werden downstream benötigt?
- Welche Teile sind bewusste Flexibilität und dürfen nicht verloren gehen?
Eine schlechte Excel-Ablösung digitalisiert nur jede Spalte und jedes Formular. Eine gute Lösung reduziert Übergaben, macht Zustände explizit und lässt seltene Ausnahmefälle kontrolliert zu. Manchmal genügt eine zentrale Datenquelle mit einem kleinen Internal Tool; nicht jeder Prozess braucht eine breite Custom-Plattform.
Die Discovery muss den realen Betrieb untersuchen
Eine Modernisierungs-Discovery sollte mehr liefern als eine technische Codeanalyse. Die wichtigsten Artefakte sind:
System- und Datenkarte
Welche Anwendungen, Tabellen, Datenbanken, Dateispeicher und Anbieter existieren? Welche Daten fließen zwischen ihnen, in welchem Format und mit welchem Owner? Wo finden manuelle Korrekturen statt?
Prozesskarte mit Ausnahmen
Der „Happy Path“ ist selten das Problem. Relevant sind Stornos, nachträgliche Änderungen, unvollständige Datensätze, Vertretungen, Sonderkunden und Monatsabschlüsse. Fachanwender sollten einen echten Vorgang durch das heutige System führen.
Risikoregister
Welche Abhängigkeit kann den Betrieb stoppen? Welche Daten sind schlecht oder unvollständig? Welche Verträge, Lizenzen oder Zugänge fehlen? Welche Personen tragen exklusives Wissen?
Migrationsoptionen
Für jede Domäne sollte sichtbar sein: stabilisieren, kapseln, integrieren, neu bauen, durch Standardsoftware ersetzen oder stilllegen. „Neu bauen“ ist nur eine von mehreren Optionen.
Erste dünne Phase
Die erste Lieferung muss klein genug für einen kontrollierten Cutover sein und groß genug, um echten Fachnutzen zu erzeugen. Ein reines technisches Fundament ohne nutzbaren Prozess ist schwer abzunehmen.
SAP, DATEV, CRM und andere Integrationen richtig bewerten
Der Name des Systems sagt wenig über den Aufwand. Entscheidend sind konkrete Produkte, Versionen, Module, APIs, Datenobjekte und Betriebsbedingungen. Eine moderne REST-API kann den Scope begrenzen; eine dateibasierte Übergabe kann ebenfalls ausreichend sein, wenn sie stabil, nachvollziehbar und fachlich passend ist.
Vor einer Schätzung sollten mindestens diese Punkte geklärt werden:
- lesender oder schreibender Zugriff;
- synchrone oder zeitversetzte Verarbeitung;
- Quelle der Wahrheit pro Datenobjekt;
- eindeutige Identifikatoren und Mapping;
- Fehler-, Retry- und Reconciliation-Prozess;
- Testsystem und repräsentative Testdaten;
- Rate Limits, Wartungsfenster und Anbieter-Support;
- Audit- und Exportanforderungen.
Nicht jede Integration muss in Echtzeit laufen. Ein kontrollierter täglicher Export kann besser sein als eine komplexe Event-Architektur, wenn der Fachprozess keine Sekundengenauigkeit benötigt. Der Partner sollte diese Trade-offs erklären können.
Betriebsrat und Datenschutz gehören in die Planung — nicht als Engineering-Versprechen
Interne Tools können Arbeitsabläufe, Zuständigkeiten und Leistungsdaten sichtbar machen. Wo eine technische Einrichtung dazu bestimmt ist, Verhalten oder Leistung von Beschäftigten zu überwachen, nennt § 87 Abs. 1 Nr. 6 BetrVG ein Mitbestimmungsrecht des Betriebsrats. Ob die Vorschrift im konkreten Fall greift, ist eine rechtliche und betriebliche Frage, keine Entscheidung des Entwicklungsteams.
Praktisch bedeutet das: früh klären, welche Ereignisse protokolliert werden, wer Auswertungen sieht, wie lange Daten bestehen und welchem Zweck sie dienen. Nicht jedes Audit-Log ist Mitarbeiterüberwachung; ein Protokoll für Sicherheit und Fehleranalyse hat einen anderen Zweck als ein Performance-Ranking. Die Grenzen müssen bewusst gestaltet und durch zuständige Stellen bewertet werden.
Auch die DSGVO sollte als konkreter Daten- und Rollen-Scope behandelt werden. Engineering kann Datenminimierung, Zugriffskontrolle, Löschwege und technische Schutzmaßnahmen umsetzen. Es kann keine pauschale „Rechtssicherheit“ garantieren.
Was kostet eine Mittelstand-Modernisierung?
Ohne Systemkarte ist ein Gesamtpreis nicht seriös. Als unverbindliche H-Studio-Richtwerte für B2B-Projekte können folgende Phasen zur Orientierung dienen:
| Phase | Typisches Ergebnis | Richtwert netto |
|---|---|---|
| System Mapping / Architektur-Sprint | System- und Prozesskarte, Risiken, Optionen, erste Roadmap | 3.500–7.500 € |
| Fokussierte erste Domäne | Ein nutzbarer Workflow, Integration, Deployment und Handover | etwa 25.000–70.000 € |
| Breitere Plattformphase | Mehrere Rollen, Migration, Integrationen und Operations | etwa 70.000–150.000 €+ |
| Laufende Modernisierung | Priorisierte Domänen in getrennten Lieferphasen | nach Team und Verantwortung |
Diese Beträge sind Erfahrungswerte und unverbindliche Richtwerte, keine Marktstatistik und kein Angebot. Der finale Preis hängt von Systemzustand, Datenqualität, Integrationen, Cutover-Risiko und Betriebsverantwortung ab; alle Beträge netto zzgl. gesetzlicher Umsatzsteuer, sofern anwendbar.
Der größte Kostenfehler ist ein pauschaler Gesamtvertrag, bevor Abhängigkeiten bekannt sind. Ein kleiner bezahlter Mapping-Schritt kann ergeben, dass Standardsoftware passt, ein Teil nur stabilisiert werden sollte oder der geplante Rewrite unnötig ist. Auch dieses Ergebnis ist wertvoll.
Drei echte Delivery-Beispiele
Vulken FM: Eine mobile und webbasierte Inspektionsplattform ersetzte papierbasierte Feldabläufe durch QR-Zugriff, Offline-Erfassung, strukturierte Prüfregeln und Reporting. Der Kern war nicht „Papier digitalisieren“, sondern Feld- und Office-Prozess auf einem gemeinsamen Datenmodell zu verbinden. Die Vulken FM Case Study beschreibt Architektur und Grenzen.
Forschungsmittel.com: Öffentliche Website, Kunden-Dashboard, Dokumenten-Workflow und interner Team-Workspace wurden als ein verbundenes Produktsystem aufgebaut. Das Beispiel zeigt, wie E-Mail- und Dokumentübergaben in explizite Projektzustände übersetzt werden können. Details stehen in der Forschungsmittel Case Study.
My Office Asia: Eine veraltete Listing-Seite wurde durch eine strukturierte Katalog-Plattform mit individuellem Admin-CMS und dokumentiertem Handover ersetzt. Das ist keine klassische Legacy-Migration, aber ein gutes Beispiel für kontrollierte Ownership: Datenmodell, redaktioneller Workflow und öffentliche Oberfläche wurden getrennt gestaltet. Siehe My Office Asia.
Diese Fälle beweisen keine allgemeine Erfolgsquote und sind nicht identisch mit jedem Mittelstandsprojekt. Sie zeigen unterschiedliche Muster: Papierprozess, E-Mail-/Dokumentenprozess und administrierter Datenkatalog.
Wann H-Studio nicht der richtige Partner ist
H-Studio passt nicht, wenn nur eine Standardsoftware konfiguriert werden muss, eine vollständige SAP-Transformation mit großem zertifiziertem Implementierungsteam geplant ist oder das Unternehmen keinen internen Process Owner bereitstellen kann. Wir ersetzen keine Fachverantwortung und keine rechtliche oder arbeitsrechtliche Beratung.
Wir passen zu fokussierten Modernisierungsvorhaben, bei denen ein kleines Senior-Team Systemgrenzen, Integrationen, Custom Software und Handover gemeinsam verantwortet. Der Einstieg liegt bei Mittelstand-Modernisierung, individueller Software oder einem Internal Tool. Wenn das bestehende Projekt bereits akut feststeckt, ist Projekt-Rettung der passendere Startpunkt.
Häufige Fragen
Wie löst man ein Legacy-System ohne Big-Bang-Rewrite ab?
Zuerst werden Domänen, Daten und Abhängigkeiten kartiert. Danach wird ein begrenzter Prozess neben dem Altsystem aufgebaut und kontrolliert umgestellt. Integrationen oder Router koordinieren den Übergang, bis der alte Teil deaktiviert werden kann. Parallelbetrieb, Datenabgleich und Rollback müssen ausdrücklich geplant werden.
Wann sollte ein Unternehmen Excel durch Software ersetzen?
Wenn mehrere Personen geschäftskritische Daten parallel pflegen, Versionen auseinanderlaufen, Rechte unklar sind oder wiederkehrende Übergaben viel manuelle Arbeit erzeugen. Für flexible Einzelanalysen bleibt Excel sinnvoll. Der Ersatz sollte den Prozess vereinfachen und nicht nur jede Tabellenzelle in eine Webmaske übertragen.
Was kostet eine Legacy-Modernisierung?
Ein belastbares Gesamtbudget entsteht erst nach System Mapping. Bei H-Studio liegt eine fokussierte Analyse häufig bei 3.500–7.500 € netto. Eine erste nutzbare Domäne kann etwa 25.000–70.000 € kosten; breitere Plattformphasen mit Migration und mehreren Integrationen können 70.000–150.000 € oder mehr erreichen.
Wie integriert man DATEV, SAP oder ein bestehendes ERP?
Zuerst werden Produkt, Version, Datenobjekte, verfügbare Schnittstellen und Quelle der Wahrheit geklärt. Danach entscheidet der Fachprozess, ob API, Dateiübergabe, Middleware oder ein anderer Weg passt. Fehlerbehandlung, Reconciliation und Testzugang gehören in den Scope; der Produktname allein erlaubt keine Schätzung.
Wie lange dauert eine domänenweise Migration?
Eine erste abgegrenzte Domäne kann je nach Integration in einigen Monaten nutzbar sein. Ein vollständiges Modernisierungsprogramm läuft häufig in mehreren Phasen und kann deutlich länger dauern. Wichtiger als eine pauschale Gesamtdauer sind frühe nutzbare Ergebnisse und klare Abschaltkriterien für jeden alten Teil.
Muss der Betriebsrat bei einem neuen Internal Tool beteiligt werden?
Das hängt von Funktion und Einsatz ab. Ist eine technische Einrichtung zur Überwachung von Verhalten oder Leistung bestimmt, kann § 87 Abs. 1 Nr. 6 BetrVG relevant sein. Die konkrete Bewertung gehört zu Arbeitgeber, Betriebsrat und Rechtsberatung. Das Projektteam sollte Datenerfassung und Auswertungszwecke früh transparent machen.
— Anna
Lektoriert und auf technische Plausibilität geprüft von Anna Hartung. Preisangaben sind unverbindliche H-Studio-Erfahrungswerte für B2B-Projekte. Hinweise zu DSGVO und Betriebsverfassung sind keine Rechtsberatung.