In den meisten Fällen zeigen sich die ersten Warnzeichen dort, wo niemand regelmäßig hinschaut: in Reports mit stillschweigend falschen Zahlen oder nächtlichen Jobs, die nur noch per Handauflegen durchlaufen. Eine Pipeline läuft seit vier Jahren, niemand im Team weiß mehr, wer die erste Version gebaut hat oder warum die Transformationsschritte in genau dieser Reihenfolge ablaufen. Jede Änderung in der Mitte dieser Kette verlangt, die gesamte nachfolgende Strecke zu verstehen, bevor überhaupt eine Zeile Code angefasst wird. Ein Data Warehouse, das vor fünf Jahren für den damaligen Geschäftsbedarf dimensioniert wurde, wird von Quartal zu Quartal langsamer, bis das Finanzteam eigene Datenexporte baut, weil der offizielle Auswertungsprozess zu lange dauert. Datensilos entstehen dabei kaum aus Unwillen der Teams: Die Kosten für eine systemübergreifende Integration steigen mit jedem Jahr, und Workarounds wirken am Ende günstiger als die eigentliche Lösung.

Modernisierung ist für uns die Antwort auf konkrete Einschränkungen, unabhängig von persönlichen Technologievorlieben. Zuerst analysieren wir die Blockaden der bestehenden Plattform und ihre Kosten für dein Unternehmen. Erst danach folgt eine Empfehlung für einen bestimmten Technologie-Stack. Das gilt unabhängig von Branche und Ausgangslage.

Besonders oft begegnen uns dabei drei Situationen: regulierte Branchen im DACH-Raum, allen voran Finanzdienstleister, für die jede Datenbewegung während der Migration unter Aufsicht steht; filialbasierte Unternehmen mit isolierten Datenbanken, bei denen Finanz- und Logistikdaten sowie Verkaufszahlen noch von Hand abgeglichen werden; und Unternehmen, deren KI-Pilotprojekte an der bestehenden Dateninfrastruktur scheitern, bevor sie überhaupt in Produktion gehen.

So gehen wir in drei Phasen vor

Eine vollständige Neuentwicklung in einem Schritt wäre für die meisten Unternehmen ein zu großes Risiko. Die Migration läuft deshalb schrittweise ab, alte sowie neue Systeme parallel während der gesamten Umstellung:

| Phase | Dauer | Was passiert | |---|---|---| | 1. Analyse und Migrationspriorisierung | 1–2 Wochen | Wir erfassen, was auf deiner Plattform läuft und wo Betriebskosten sowie Schwachstellen die größten Blockaden erzeugen. Du bekommst eine nach geschäftlichem Nutzen und technischem Risiko gestaffelte Migrationsreihenfolge. | | 2. Phasenweise Migration | 6–16 Wochen, je nach Umfang | Alte und neue Systeme laufen parallel. Sobald eine Komponente validiert ist, übernimmt sie den Datenverkehr. Klare Vereinbarungen zwischen Produzenten und Konsumenten machen jede Änderung sofort erkennbar, bevor sie in einem nachgelagerten System zu Problemen führt. | | 3. Übergabe und Betriebsfähigkeit | 2–4 Wochen | Dein Team erhält die nötigen Unterlagen und eine praxisnahe Einweisung, um das System künftig selbständig weiterzuentwickeln. |

Ein Discovery Workshop von drei bis zehn Tagen ist der übliche Einstieg für Unternehmen, die vor der Migrationsentscheidung erst eine Analyse brauchen. Unternehmen, die bereits wissen, was migriert werden muss, planen die Migration direkt und überspringen die separate Analysephase.

Bausteine der Modernisierung

Jeder Baustein setzt auf dem vorigen auf und bringt dich einen Schritt näher an die eigenständige Betriebsfähigkeit.

1. Zielarchitektur auswählen. Empfehlungen basieren auf realen Anwendungsfällen, Datenvolumen, den Fähigkeiten deines Teams und bestehenden Investitionen; persönliche Anbietervorlieben bleiben dabei außen vor. Jede Entscheidung wird dokumentiert, damit dein Team sie unabhängig nachvollziehen kann, auch Monate später noch. Für Data Warehousing kommen Snowflake, BigQuery oder Redshift infrage, für Tabellenformate Delta Lake oder Apache Iceberg, für die Orchestrierung Airflow oder Prefect, für Transformationen dbt. Wir arbeiten mit dem bestehenden Stack oder empfehlen situationsabhängig eine Alternative.

2. Datenverträge gestalten. Noch vor Beginn der Migration legen wir zwischen Produzenten und Konsumenten explizite Vereinbarungen zu Schema und Lieferfrequenz fest, ergänzt um klare Regeln für zulässige Änderungsbenachrichtigungen. Vorgelagerte Änderungen werden so sichtbar, bevor sie erst in einem fehlerhaften Dashboard auffallen und Stunden an Fehlersuche kosten. Ändert ein Team später ein Schema, meldet der Vertrag das automatisch an alle betroffenen Konsumenten.

3. Phasenweise Migration im laufenden Betrieb. Alte und neue Systeme laufen während der gesamten Umstellung parallel. Jede Komponente wird unter Produktionslast geprüft, bevor der Datenverkehr umzieht, und ein Rollback bleibt jederzeit möglich.

Bei einer der größten Handelsgenossenschaften Europas außerhalb des Lebensmittelbereichs, mit mehr als 5.500 betreuten Einzelhändlern in sieben Ländern, hatte sich unter der äußerlich stabilen Plattform über Jahre ein System angesammelt, das niemand mehr vollständig verstand: undokumentierte Änderungen und fest verdrahtete Geschäftslogik voller unsichtbarer Abhängigkeiten. Sechs Monate lang beschäftigten wir uns ausschließlich mit dem bestehenden System: Wir lasen Quellcode und verfolgten Abhängigkeiten nach, rekonstruierten außerdem gemeinsam mit langjährigen Mitarbeitenden die Geschäftsregeln – und schlugen erst danach eine einzige Änderung vor. Die Abweichungen bei Preisen und Beständen zwischen den Systemen gingen danach um die Hälfte zurück, und es entstand die erste vollständige Systemdokumentation der Plattform.

4. Übergabe an dein Team. Das System, das du übernimmst, läuft danach vollständig in der Eigenregie deines Teams. Wir sorgen mit Runbooks, Architekturdokumentation und Entscheidungslogs sowie praxisnahen Schulungen dafür, dass dein Team die Plattform eigenständig und täglich bedienen kann.

Datengovernance und Datenresidenz während der Migration

Zwischen alten und neuen Systemen wandern Daten mitunter über unterschiedliche Infrastrukturanbieter hinweg, und genau in diesen Übergängen entscheidet sich, ob sensible Daten dort bleiben, wo sie bleiben müssen. Das verlangt eine ausdrückliche Governance in jeder einzelnen Phase, von Anfang an. Deshalb betreiben wir alte und neue Systeme während der gesamten Migration parallel innerhalb derselben geprüften Infrastruktur und führen Daten ausschließlich durch bereits geprüfte Umgebungen. Genau darauf kommt es an, wenn dein Geschäft täglich Hunderttausende Transaktionen unter behördlicher Aufsicht verarbeitet.

Referenzprojekte in Zahlen

So sieht das in der Praxis aus, anhand von drei Beispielen aus produktiven Einsätzen:

• Bankentechnologieanbieter aus der Schweiz: über 300 Kernbankanwendungen, 500.000 Transaktionen täglich, mehrjährige Cloud-Migration unter den Datensouveränitätsanforderungen der FINMA; Architekturprüfung für alle 300 Anwendungen, konforme Multi-Cloud-Grundlage auf Azure und Google Cloud, ein hybrides Betriebsmodell für den parallelen Betrieb während der gesamten Migration, dazu Schulung und Zertifizierung der internen Teams; die entstandene Architektur bestand das Sicherheits- und Compliance-Audit einer der vier großen Prüfungsgesellschaften beanstandungsfrei.
• Größte Kaffeehauskette Vietnams: 928 Filialen, vier isolierte Datenbanken für Finanzen und Verkauf sowie die Logistik, die nie für eine Zusammenarbeit konzipiert worden waren und zuvor manuell abgeglichen wurden; Konsolidierung in einem zentralen Data Warehouse mit eigens entwickelten Schnittstellen und einer Reporting-Schicht für Echtzeit-Transparenz je Filiale; der Umsatz stieg innerhalb von drei Monaten um 12 Prozent, weil Entscheidungen, für die zuvor eine Woche Datenaufbereitung nötig war, am selben Tag getroffen werden konnten.
• Lebensmittel- und Getränke-Distributor aus Japan: wachsende Zahl angebundener Lieferanten mit uneinheitlichen Datenformaten und Schemata, dazu ein Governance-Defizit bei Rollen und Freigabeprozessen; Einführung von Pimcore als zentralem Master-Data-Management-System mit automatisierten Importpipelines und rollenbasierten Zugriffskontrollen, komplett mit japanischer Sprachunterstützung; die Anbindung eines neuen Lieferanten dauert seitdem nur noch eine Woche – zuvor waren es vier.

Die Datenplattform als Grundlage für KI

Scheitert ein KI-Pilotprojekt an einer fragmentierten Dateninfrastruktur, zeigt sich das meist erst, wenn schon Zeit und Budget investiert sind. Wenn eine größere Investition erst Gewissheit über die KI-Tauglichkeit deiner Plattform verlangt, ist eine Datenbewertung der richtige Einstieg – ein kompakter erster Schritt vor dem vollen Projekt.

In einem achtwöchigen Projekt aus Discovery und Prototyp klärten wir bei procelo, einem Softwareunternehmen aus der Schweiz, genau das, bevor in die volle Produktentwicklung investiert wurde. Im Weg standen dabei zwei Hürden: ein Datenmodell, das über unterschiedlich strukturierte ERP-Schemata verschiedener Anbieter hinweg zuverlässig funktioniert, und die Genauigkeit der KI-gestützten SQL-Generierung, bei der Sprachmodelle plausibel aussehendes, aber falsches SQL erzeugen können. Ein dreiköpfiges Team entwickelte eine Architektur aus primärer SQL-Datenbank und sekundärer Vektordatenbank, die dem KI-Agenten bei der Abfrage zusätzlichen Kontext lieferte. Das Prototyp-System erreichte eine SQL-Abfragegenauigkeit von über 80 Prozent über unterschiedliche ERP-Schemata hinweg und lieferte damit den Machbarkeitsnachweis für die Investitionsentscheidung, innerhalb der veranschlagten acht Wochen.

Wege in die Zusammenarbeit

Wir bündeln die Modernisierungsleistungen in zwei Paketen, je nachdem, wie weit deine Entscheidung schon gereift ist.

| Paket | Dauer | Inhalt | |---|---|---| | Discovery Workshop | 3–10 Tage | In diesem strukturierten, zeitlich begrenzten Engagement decken wir gemeinsam mit deiner Führungsebene Engpässe auf und erarbeiten Lösungswege, dazu beraten wir bei schwierigen Kompromissen und Budgetentscheidungen. | | Realignierungs-Projekt | mindestens 3 Monate | Enge Zusammenarbeit mit deiner Führungsebene für eine strukturierte Umsetzung; die überarbeitete Strategie wird in Architektur und Betriebsmodelle übersetzt, bis hin zu den Liefer-Roadmaps. |

Ein klarer Migrationspfad steht am Ende jedes Pakets – konkret und mit einem definierten nächsten Schritt. Ein SaaS-Kosten-Audit und ein Audit zur Skalierungsfähigkeit sind außerdem verwandt, falls dein größter Engpass eher im Werkzeugbudget oder im Wachstumstempo liegt als in der Datenplattform selbst.