Vom Zoo zur Architektur. Der pragmatische Migrationspfad.

“Wie kommen wir dort konkret hin, ohne Big Bang, mit laufendem Betrieb, mit einem Geschäft, das morgen weiterläuft?”

Diese Frage haben wir in den letzten Wochen oft gehört. Sie kommt selten aus der IT, fast immer aus der Geschäftsleitung. Genau dort gehört sie auch hin. Migration ist keine Technik-Frage. Sie ist eine strategische und finanzielle Entscheidung mit technischer Konsequenz.

Dieser fünfte und letzte Teil der Greenfield-Serie ist die Antwort. Er enthält den Migrationspfad, den wir bei unseren Kunden empfehlen würden. Eine Roadmap über drei Jahre, das Auswahl-Vorgehen in sieben Phasen, eine ehrliche Business-Case-Rechnung mit Hebel-Kategorien und am Ende die fünf Fehler, die wir bei Migrationen immer wieder sehen.

Big Bang oder Etappen?

Beide Wege gibt es, beide haben ihre Berechtigung. Big Bang heißt: Die gesamte Tool-Landschaft wird in einem großen Projekt umgestellt, mit einem festen Go-Live-Termin. Das ist kurzfristig schmerzhaft, langfristig manchmal richtig. Aber selten realistisch, vor allem für einen Mittelständler mit laufendem Geschäft und begrenzter Projektreserve.

Etappen-Migration heißt: Die Zielarchitektur steht, die Umsetzung erfolgt über mehrere Jahre in beherrschbaren Schritten. Pragmatisch, kontrollierbar, finanzierbar. Aber sie braucht einen klaren Plan und Disziplin. Sonst wird aus drei Jahren Strategie das, was wir in Teil 1 seziert haben: der nächste Zoo.

Unsere Empfehlung in der überwiegenden Mehrzahl der Projekte ist eindeutig. Zielarchitektur first, der große Plan. Migration in Drei-Jahres-Etappen, die kleinen Schritte. Beides muss zusammenpassen, sonst geht eines von beiden verloren.

Die Roadmap im Großen: drei Jahre, drei Etappen

Wie sehen diese drei Jahre konkret aus? In den allermeisten Migrationen, die wir begleiten, lassen sie sich in drei Etappen mit klaren Ergebnissen am Ende jeder Phase ordnen.

Jahr 1: Strategie und Quick Wins

Im ersten Jahr passieren drei Dinge parallel. Erstens die strategische Klärung: Zielarchitektur, Steering und Business Case, also die Phasen 1 und 2 der Auswahl-Methodik, die wir gleich noch genauer ansehen. Zweitens die Quick Wins, die unabhängig von der großen Strategie sofort Geld und Komplexität sparen: Lizenz-Audit, Schnittstellen-Inventur, Stammdaten-Sanity-Check. Drittens der Start der ersten konkreten Plattform-Auswahl, in der Regel des ERP-Kerns oder einer ähnlich zentralen Komponente.

Jahr 2: Erste Konsolidierung

Im zweiten Jahr geht die erste Plattform live, mit Pilot, Roll-out und Stabilisierung. Parallel läuft die nächste Auswahl von der Anforderungs-Definition bis zum Vertrag. Und genau in dieser Phase entsteht die Daten-Architektur als eigene Disziplin: Master Data, Datenverträge zwischen Systemen, erste Bereinigungs-Wellen.

Jahr 3: Symbiose verankern

Im dritten Jahr nimmt die Symbiose sichtbar Form an. Die zweite Plattform geht live, die Schnittstellen-Landschaft schrumpft, der KI-Daten-Layer wird als eigene Schicht aufgebaut. Vor allem aber wird das Governance-Modell aus Teil 4 produktiv: Rollen sind besetzt, Routinen leben, Schatten-IT wird kanalisiert.

Drei Jahre sind eine indikative Größe, kein Naturgesetz. Manche Migrationen brauchen vier, manche schaffen es in zweieinhalb. Was wir in praktisch jedem Projekt sehen: weniger als zwei Jahre wird zu hektisch, mehr als vier verliert den Schub.

→ Eine gute Migration beginnt nicht mit der Technik, sondern mit der Strategie.

Quick Wins und strategische Hebel parallel anpacken

Einer der häufigsten Fehler ist die Trennung von Quick Wins und Strategie. Das große Ziel werde ja gerade entwickelt, heißt es dann, deshalb keine kleinen Schritte vorab. Das kostet doppelt: Glaubwürdigkeit im Haus und sofortige Einsparungen, die niemand wieder zurückbekommt.

Quick Wins sind die Hebel, die unabhängig von der Zielarchitektur funktionieren. Ein ehrliches Lizenz-Audit findet in fast jedem Haus sechsstellige Beträge an stillgelegten Modulen oder Vollzeit-Lizenzen für Gelegenheitsnutzer. Eine Schnittstellen-Inventur deckt auf, welche Punkt-zu-Punkt-Verbindungen niemand mehr braucht. Und ein Stammdaten-Sanity-Check entlastet jede spätere Migration.

Strategische Hebel brauchen den großen Plan. Die Plattform-Konsolidierung ist der offensichtlichste, weil sie direkt am Symbiose-Modell hängt. Die Daten-Architektur ist der weniger sichtbare, aber langfristig wichtigste, weil sie über alle Plattformwechsel hinweg Bestand hat. Und das Governance-Modell ist der menschlichste, weil es Verantwortung zementiert, nicht Technologie.

Das Auswahl-Vorgehen: die sieben Prozept-Phasen

Jede Plattform-Entscheidung in der Migration durchläuft denselben Rahmen. Wir nennen ihn die Prozept-Methodik, und sie besteht aus sieben Phasen. Sie ist nicht der einzige Weg, eine gute Software-Auswahl zu treffen. Aber sie ist der Weg, mit dem wir die wenigsten teuren Überraschungen sehen.

1. Strategische Vorbereitung: Steering Committee, Projektorganisation, Business Case, Ziele, Change-Strategie

2. IST-Analyse und Reifegrad: End-to-End-Prozesse, Systemlandschaft, Datenqualität, Migrationsaufwand

3. Anforderungen (MoSCoW): Must, Should, Could, Won’t. Use Cases. Akzeptanzkriterien

4. Marktanalyse und Shortlist: Longlist, Must-have-Filter, drei bis fünf Anbieter, Kultur und Support

5. RFP und Bewertung: Standardisierte Ausschreibung, Bewertungsmatrix, transparente Gewichtung

6. PoC und Live-Demos: Echte Daten und Use Cases, Key-User-Bewertung, Referenzen

7. Entscheidung und Vertrag: TCO über fünf Jahre, SLAs, Datenportabilität, IP, Governance

Drei Beobachtungen zu dieser Methodik. Erstens: die wichtigsten Phasen sind die ersten beiden. Wer Phase 1 (Strategische Vorbereitung) und Phase 2 (IST-Analyse und Reifegrad) ernst nimmt, hat die spätere Anpassungs-Diskussion schon zur Hälfte gewonnen. Wer sie überspringt, zahlt es in Phase 6 oder 7 mit Zinseszins zurück.

Zweitens: Phase 6 (PoC und Live-Demos) ist die einzige, in der echte Daten und echte Use Cases verhandelt werden. Alles davor sind Versprechen. Wer dieser Phase nicht genug Raum gibt, kauft ein Werkzeug nach Marketing-Folien.

Drittens: die Methodik endet mit Phase 7, der Entscheidung und dem Vertrag. Die Implementierung ist bewusst nicht Teil der Auswahl. Sie ist ein eigener Scope mit eigenen Rollen, eigenem Budget und eigener Verantwortung. Wer beides vermischt, verliert die Klarheit beider Disziplinen.

Der Business Case: was die Migration wirklich wert ist

Eine Migration kostet Geld, viel Geld. Drei Jahre konzentrierte Arbeit, mehrere Plattform-Umstellungen, externe Begleitung, internes Change. Die Frage ist nicht, ob sie etwas kostet. Sie ist, wo der Wert herkommt.

Wir sehen in jeder Migration vier Hebel-Kategorien, die zusammen den Business Case bilden. Sie sind unterschiedlich gut messbar, aber alle vier zählen.

Direkte Einsparungen sind die offensichtlichsten: stillgelegte Module, weggefallene Schnittstellen-Wartung, konsolidierte Verträge. Sie tauchen unmittelbar im Budget auf und sind die leichteste Argumentationsgrundlage im CFO-Gespräch.

Indirekte Einsparungen sind die größeren, aber schwerer beweisbaren. Effizienzgewinne durch schlankere Prozesse, weniger Datenfehler, weniger Schulungsaufwand für inkonsistente Systemlandschaften. Sie summieren sich oft auf das Doppelte oder Dreifache der direkten Einsparungen.

Vermiedene Risiken sind das, was nicht passiert. Compliance-Lücken, Cyber-Vorfälle, Innovations-Stillstand, weil das Alt-System nichts Neues hergibt. Schwer zu quantifizieren, aber in der Vorstands-Sitzung oft das schlagende Argument.

Strategischer Wert lässt sich kaum in Euro fassen, aber er entscheidet langfristig. Geschwindigkeit, mit der das Unternehmen auf Marktveränderungen reagieren kann. Skalierbarkeit. Anschlussfähigkeit für KI und Daten-Produkte, die in fünf Jahren Standard sein werden.

Dem stehen die genannten Investitionen über drei Jahre gegenüber, typischerweise im Bereich von 900.000 bis 1.400.000 Euro. Lizenz-Umstellung, externe Begleitung, internes Change, Implementierungsaufwand. Der Saldo wird in den meisten Projekten ab Jahr zwei oder drei positiv, der strategische Wert kommt obendrauf und wirkt deutlich länger.

→ Niemand wartet, bis das Haus brennt. Bei der IT-Architektur tun wir es trotzdem.

Fünf Fehler, die wir bei Migrationen immer wieder sehen

Wir kommen nicht oft in Projekte, in denen alles glattläuft. Das liegt in der Natur unseres Geschäfts. Aber genau deshalb können wir sagen, welche Fehler sich wiederholen. Fünf sind es, und alle fünf sind vermeidbar, wenn die ersten Wochen ernst genommen werden.

1. Technik vor Strategie
Der Klassiker. Eine Technologie-Konferenz, ein begeisterter CIO, ein Anbieter mit beeindruckender Roadmap, und schon ist die Auswahl im Gang, bevor die Zielarchitektur überhaupt steht. Das Ergebnis ist immer dasselbe. Das Tool ist gekauft, der Prozess passt nicht, und die nächsten zwölf Monate gehen mit Workarounds drauf.

2. Phasen 1 und 2 überspringen
Die strategische Vorbereitung und die IST-Analyse sehen auf den ersten Blick nach Beratungs-Folklore aus. Vier Wochen Workshops, viele Folien, am Ende ein Steering und ein Business Case. Aber genau diese vier Wochen entscheiden, ob die nächsten zweieinhalb Jahre laufen oder rückwärts korrigiert werden müssen.

3. Big Bang als Kompromiss
Das Etappen-Vorgehen ist klar besser, sagt unsere Empfehlung. Aber drei Jahre sind lang, und die Geschäftsführung wünscht sich Tempo. Aus dem Wunsch wird ein Versuch, mehrere Plattformen gleichzeitig umzustellen. Das Risiko vervielfacht sich, die Komplexität steigt nicht-linear, und der Betrieb leidet sichtbar.

4. Quick Wins ignorieren
Eine seltsame Loyalität gegenüber der großen Strategie führt manchmal dazu, dass offensichtliche Hebel liegen gelassen werden, bis die Architektur fertig ist. Das ist falsch verstandene Disziplin. Quick Wins schaffen Glaubwürdigkeit im Haus, finanzieren einen Teil der späteren Investitionen und beweisen, dass das Vorhaben wirklich Effekte hat.

5. Governance erst am Ende
Der teuerste Fehler. Die Plattform-Auswahl ist abgeschlossen, das System ist implementiert, und erst dann beginnt die Diskussion, wer eigentlich für was zuständig ist. Inzwischen haben fünf Fachbereiche eigene Datenstrukturen aufgebaut, jeder Workflow ein leicht anderes Verständnis, und das Governance-Modell aus Teil 4 wird zum nachträglichen Aufräumen statt zum Fundament.

Was bleibt

Wir hatten am Anfang dieser Serie ein Geständnis abgelegt. Berater leben gut von Komplexität. Wir leben gut von Best-of-Breed der 2000er, von Lizenz-Verhandlungen mit drei Anbietern, von KI-Eigenbau-Wellen, von Migrations-Programmen über drei Jahre. Wir leben sogar von genau dem Zoo, den wir in Teil 1 seziert haben.

Mit dieser Serie wollten wir trotzdem etwas anderes versuchen. Nicht das Versprechen, dass es einfach wird. Sondern ein ehrlicheres Beratungs-Gespräch, das mit dem Bild der Zielarchitektur beginnt und nicht mit dem nächsten Tool, das auf der Tagesordnung steht. Eines, das die kostenoptimierte Symbiose als Idee ernst nimmt, statt dem nächsten Hype hinterherzurennen. Eines, das die Frage „Wer macht das in fünf Jahren?“ lieber zu früh stellt als zu spät.

Niemand muss morgen den Big Bang machen. Aber niemand sollte heute weiter zusehen, wie der Zoo wächst, in der Hoffnung, dass die nächste Generation aufräumt.

Eine Frage zum Schluss, die Sie ruhig in Ihr nächstes IT-Strategie-Meeting mitnehmen können. Was würde Ihre Nachfolgerin Ihnen vorwerfen, wenn sie in fünf Jahren auf Ihre heutige Tool-Landschaft schaut? Und was davon können Sie ändern, ohne auf den großen Plan zu warten?

Mit diesem Teil schließt die Greenfield-Serie. Danke fürs Mitlesen. Wer mit uns weiterarbeiten möchte, ist hier richtig. Wer nicht, hat hoffentlich trotzdem ein paar Bilder im Kopf, die hängen bleiben.