Weniger Risiko dank Pilot: Migration von Altsystemen in 90 bis 180 Tagen

Für die meisten Organisationen bringt eine schrittweise Migration von Altsystemen, abgesichert durch einen Pilot und einen kontrollierten Go-live in Etappen, ein besseres Verhältnis von Risiko, Kosten und geschäftlichem Nutzen als eine Umstellung in einem einzigen Schritt. Entscheidungen zu Governance und Datenschutz prägen das Ergebnis stärker als die Wahl des Anbieters oder der Plattform. Richtig gemacht, zahlt sich das doppelt aus: geringeres Betriebsrisiko während des Übergangs und ein klares Bild der Gesamtbetriebskosten, bevor Sie weiteres Budget freigeben.

---

Kurz gefasst:

• Die meisten Organisationen fahren mit einer schrittweisen Migration besser, also mit Go-lives in Etappen und mit MVPs, statt mit einer Umstellung auf einen Schlag. Das senkt das Betriebsrisiko.

• Die Abhängigkeitsanalyse sollte sich auf undokumentierte Fachanwendungen und kleine Systeme konzentrieren. Genau dort stecken oft kritische Abläufe, die in offiziellen Diagrammen nicht auftauchen.

• Datenklassifizierung und Compliance, besonders bei Personendaten nach Schweizer Recht, brauchen eine frühe Planung und vertragliche Schutzmassnahmen, noch bevor die Migration beginnt.

• Welcher Migrationsansatz passt, hängt von der technischen Altlast des bestehenden Systems, dessen Verflechtung mit anderen Systemen und der Toleranz der Organisation für Ausfallzeiten ab.

• Ein strukturierter Plan mit den Phasen Analyse, Pilot und gestaffeltem Go-live, inklusive klarer Rollback-Strategie, schlägt jeden Plan, der nur von einem Zieldatum getrieben ist.

---

Was die Migration von Altsystemen wirklich bedeutet (und wann Sie damit anfangen)

Die Migration von Altsystemen bezeichnet den Umzug von Daten, Funktionen und Abläufen weg von einer alternden Plattform hin zu neuer Infrastruktur, sei das eine moderne Cloud-Umgebung, eine neue Anwendung oder eine neu gebaute Version desselben Systems. Der Begriff ist enger gefasst als «Modernisierung», die auch Veränderungen umfasst, bei denen gar nichts umzieht, etwa eine API-Schicht vor einem System, das exakt dort bleibt, wo es ist. Bei einer Migration wechseln Daten und Funktionen immer den Ort oder die Plattform. Modernisierung ist das übergeordnete Ziel, die Migration ist häufig der Weg dorthin.

Sie brauchen keine Krise, um damit zu beginnen, doch die meisten Organisationen warten trotzdem, bis eine da ist. Am deutlichsten sind die äusseren Auslöser: Ein Anbieter kündigt das Support-Ende der Plattform an, ein Compliance-Audit bemängelt nicht mehr unterstützte Software, oder eine neue Anbindung scheitert schlicht daran, dass das Altsystem keine brauchbare API hat.

Einige Warnzeichen zeigen sich in der Regel schon vor dem auslösenden Ereignis:

• Änderungen dauern immer länger. Eine Funktion, die vor fünf Jahren in zwei Wochen fertig war, braucht heute zwei Monate, weil niemand die Abhängigkeiten mehr ganz überblickt.

• Der Anbieter hat sich aus dem Markt zurückgezogen, liefert keine Patches mehr oder wurde übernommen und hat das Produkt zurückgestuft.

• Sicherheitsvorfälle oder Beinahe-Vorfälle häufen sich, oft im Zusammenhang mit Komponenten, die sich nicht aktualisieren lassen, ohne dass anderes kaputtgeht.

• Die Wartungskosten steigen schneller als der geschäftliche Nutzen, den das System liefert.

• Neue Mitarbeitende lassen sich nur einarbeiten, wenn ein oder zwei Personen, die das System gebaut haben, monatelang ihr Erfahrungswissen weitergeben.

Treffen zwei oder mehr dieser Punkte zu, lohnt sich eine Analyse schon vor der Budgetdiskussion. Wer wartet, bis der Anbieter die Entscheidung erzwingt, migriert fast immer unter grösserem Zeitdruck und mit weniger Verhandlungsspielraum.

Migrationsansätze im Vergleich: Lift-and-Shift, Replatforming, Refactoring und Strangler Pattern

Den einen «richtigen» Migrationsansatz gibt es nicht. Welcher passt, hängt davon ab, wie viel technische Altlast das heutige System mitschleppt, wie eng es mit anderen Systemen verflochten ist und wie viel Risiko das Geschäft während des Übergangs verträgt.

Lift-and-Shift verschiebt die Anwendung unverändert auf neue Infrastruktur, meist Cloud-Server, mit minimalen Codeanpassungen. Das ist zu Beginn die schnellste und günstigste Variante und eine vernünftige Wahl, wenn die Anwendungslogik noch gut funktioniert und das eigentliche Problem die darunterliegende Hardware oder das Hosting ist. Der Nachteil: Sie erben jeden architektonischen Mangel des alten Systems, einfach auf neuerer Infrastruktur. Das kauft Zeit, bringt aber keine Verbesserung.

Replatforming nimmt moderate Änderungen vor, häufig einen Wechsel der Datenbank oder Anpassungen, damit die Anwendung mit Cloud-Diensten zusammenspielt, ohne alles neu zu schreiben. Bei Kosten und Risiko liegt dieser Weg in der Mitte, und er ist oft richtig, wenn die fachliche Logik solide ist, die Datenschicht oder das Deployment-Modell aber bremst.

Refactoring oder eine vollständige Neuentwicklung baut die Anwendung auf moderner Architektur neu auf, teils mit einem komplett überdachten Datenmodell und neuen Abläufen. Das ist der teuerste und langwierigste Weg, aber der einzige, der technische Altlast tatsächlich beseitigt statt nur verschiebt. Sinnvoll ist er, wenn sich die fachliche Logik selbst ändern muss und nicht nur die Infrastruktur darunter.

Das Strangler Pattern ersetzt das Altsystem Stück für Stück: Neue Funktionen laufen über moderne Dienste, während das alte System die noch nicht migrierten Teile weiterbetreibt. Mit der Zeit schrumpft der Altbestand, bis er abgeschaltet werden kann. Dieser Ansatz vermeidet das Alles-oder-nichts-Risiko einer Umstellung auf einen Schlag und liefert laufend Nutzen, statt jahrelang auf einen einzigen Go-live zu warten. Modernization guidance from Swisscom empfiehlt genau das: mit MVPs in der Public Cloud starten, diese in die bestehende Umgebung zurückintegrieren und auf einen hybriden Zustand hinarbeiten, statt einen grossen Sprung zu versuchen.

Die Entscheidung hängt meist davon ab, wie eng Ihre Systeme verflochten sind und wie viel Ausfallzeit das Geschäft verkraftet. Bei einem eng gekoppelten Monolithen mit Dutzenden von Schnittstellen spricht fast immer alles für das Strangler Pattern oder ein Replatforming in Etappen statt für eine Neuentwicklung, schon weil eine komplette Neuentwicklung sämtliche abhängigen Schnittstellen bis ganz zum Schluss aufschiebt.

Ein Migrationsplan, der den Kontakt mit der Realität übersteht

Ein Plan, der nur um ein Zieldatum herum gebaut ist und keine Zwischenkontrollen kennt, fällt in der Regel in dem Moment auseinander, in dem die erste unerwartete Abhängigkeit auftaucht. Besser ist eine Struktur mit drei Phasen, jede mit einem konkreten Ergebnis, das die nächste freigibt.

1. Analyse. Bevor die erste Zeile Migrationscode entsteht, brauchen Sie ein vollständiges Anwendungsinventar, eine Abhängigkeitskarte, die zeigt, welche Systeme miteinander sprechen, eine Datenklassifizierung, die Personendaten von betrieblichen Daten trennt, sowie ein Kosten- und Risikoprofil des Ist-Zustands. Diese Phase dauert regelmässig länger als erwartet, meist weil die Abhängigkeitsanalyse Schnittstellen zutage fördert, an die sich niemand mehr erinnert hat.

2. Pilot oder MVP. Wählen Sie eine Arbeitslast, idealerweise risikoarm, aber repräsentativ für die Komplexität des Gesamtsystems, und migrieren Sie sie vollständig. Ziel ist nicht Tempo, sondern Bestätigung. Ein erfolgreicher Pilot beweist, dass der gewählte Ansatz mit Ihren echten Datenmengen, Ihren echten Integrationsmustern und Ihren echten Leistungsanforderungen zurechtkommt, nicht mit einem vereinfachten Testfall. Legen Sie die Erfolgskriterien vorher fest: bestandene Prüfungen der Datentreue, Leistung innerhalb einer vereinbarten Schwelle sowie ein getestetes, funktionierendes Rollback.

3. Go-live in Etappen. Ordnen Sie die verbleibenden Arbeitslasten nach Risiko und beginnen Sie mit den Systemen, die am wenigsten Risiko und Sichtbarkeit mitbringen. Jede Etappe braucht ihr eigenes Runbook, ihr eigenes Monitoring und einen getesteten Rollback-Weg, und zwar vor dem Go-live, nicht danach. Das Migration Acceleration Program von AWS beschreibt das als dreistufigen Weg von der Analyse über die Mobilisierung bis zu Migration und Modernisierung und hebt ausdrücklich hervor, dass die Unterstützung durch die Führung den Erfolg stärker vorhersagt als der gewählte Technologie-Stack.

Praxistipp: Behandeln Sie den Rollback-Plan als vollwertiges Ergebnis, nicht als Nachgedanken. Wenn Sie vor dem Go-live nicht beantworten können, wie Sie diese Etappe in weniger als vier Stunden zurücknehmen, sind Sie nicht bereit für den Go-live.

Eine Budgetreserve gehört ausdrücklich in diesen Plan. Gartner-nahe Auswertungen gescheiterter Technologieprojekte nennen als häufigsten Abbruchgrund die schwache Verbindung zwischen technischen Meilensteinen und Geschäftszielen, dazu Gesamtbetriebskosten, die unbemerkt über das von der Führung bewilligte Mass hinauswachsen. Wer jede Etappe an ein messbares geschäftliches Ergebnis knüpft und nicht nur an einen technischen Zwischenstand, kann das Projekt auch dann verteidigen, wenn die Budgetgespräche härter werden.

Datenmigration, Datenschutz und was das Schweizer Recht tatsächlich verlangt

Ihre Daten zu erfassen und zu klassifizieren steht vor jeder technischen Migrationsarbeit, nicht daneben. Trennen Sie Personendaten früh von rein betrieblichen oder geschäftlichen Daten, denn beide bringen sehr unterschiedliche Pflichten mit sich, sobald sie Ihre heutige Infrastruktur verlassen.

Nach dem Schweizer Datenschutzgesetz (DSG) bleibt die Organisation rechtlich für Personendaten verantwortlich, auch wenn die Bearbeitung an einen Cloud-Anbieter oder einen Outsourcing-Partner übergeht. Auslagern überträgt die Haftung nicht. Wenn Ihre Migration Personendaten in einen Cloud-Dienst verschiebt, insbesondere ausserhalb der Schweiz, brauchen Sie dokumentierte technische oder vertragliche Schutzmassnahmen. Der EDÖB, also der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte, erwartet diese Massnahmen vor der Übermittlung und nicht nachträglich. Zur Fallgeschichte des EDÖB gehört eine formelle Prüfung der Auslagerung von Personendaten der SUVA an einen Microsoft-Cloud-Dienst. Sie hat deutlich gemacht, dass auch grosse, gut ausgestattete Organisationen vor dem endgültigen Entscheid für ein Cloud-Outsourcing eine unabhängige Beurteilung der Datenschutzrisiken brauchen.

Praktische Massnahmen, die einer aufsichtsrechtlichen Prüfung standhalten:

• Personendaten pseudonymisieren oder anonymisieren, wo der Anwendungsfall es zulässt. Das verringert den Schaden bei einer Verletzung der Datensicherheit.

• Daten sowohl im Ruhezustand als auch während der Übertragung verschlüsseln, besonders bei jeder grenzüberschreitenden Übermittlung.

• Protokolle führen, die zeigen, wer während und nach der Migration auf welche Daten zugegriffen hat.

• Anbieterprüfungen mit Fragebogen durchführen, bevor ein Auslagerungsvertrag unterschrieben wird, nicht danach.

• Vertragsklauseln zu Datenstandort, Meldefristen bei Vorfällen und Einsatz von Unterauftragnehmern aufsetzen.

Der EDÖB prüft Standardklauseln zum Datenschutz gemäss seinen eigenen Hinweisen zum Outsourcing in der Regel innerhalb weniger Monate. Das sollten Sie im Zeitplan berücksichtigen, wenn Ihre Migration von einer neuen Vereinbarung zur grenzüberschreitenden Datenbearbeitung abhängt. Planen Sie dieses Zeitfenster ein, statt es erst in der Pilotphase zu entdecken.

Technische Knacknüsse: Abhängigkeiten, Datenbanken und Integrationsmuster

An der Abhängigkeitsanalyse scheitern die meisten Zeitpläne, und schuld daran sind fast nie die Systeme, die alle kennen. Es sind die kleinen Fachanwendungen, die eine Abteilung vor Jahren gebaut und nie formell dokumentiert hat und die im Stillen kritische Abläufe zusammenhalten. Um sie zu finden, müssen Sie mit den Menschen sprechen, die das System täglich nutzen, und nicht nur das Architekturdiagramm lesen, das jemand vor fünf Jahren gezeichnet hat.

Die Datenbankmigration bringt eigene Realitäten mit, die Teams unterschätzen. Schemaänderungen verlangen bei jedem Schritt Prüfungen der Datentreue, also den Vergleich von Datensatzzahlen, Prüfsummen und Stichproben zwischen altem und neuem System, bevor Sie der Migration trauen. Die Leistungsoptimierung auf der neuen Plattform folgt fast immer anderen Regeln als auf der alten Datenbank, besonders beim Wechsel von einer relationalen Datenbank im eigenen Rechenzentrum zu einer Cloud- oder In-Memory-Alternative. Auch die Testdatenstrategie zählt: Tests gegen eine bereinigte Kopie der Produktionsdaten finden Probleme, die synthetische Testdaten nie aufdecken.

Für die Integration decken drei Muster die meisten Situationen ab:

• API-Fassaden hüllen das Altsystem in eine moderne Schnittstelle, sodass neue Anwendungen damit sprechen können, ohne den alten Code anzufassen.

• Adapter und Message-Busse entkoppeln Systeme, die früher direkt miteinander kommunizierten, und begrenzen den Schaden, wenn sich eine Seite ändert.

• Schrittweise Umstellungen leiten einen Teil des Verkehrs auf das neue System, während der Rest auf dem alten bleibt. So erkennen Sie Probleme im Kleinen, bevor Sie sich ganz festlegen.

Praxistipp: Automatisieren Sie Ihr Rollback genauso wie Ihr Deployment. Ein manuelles Rollback unter Druck, mitten in einer Störung, um 2 Uhr nachts: Genau dort werden Migrationen zu Schlagzeilen. Infrastructure as Code, Pipelines für Continuous Integration und Delivery sowie automatisierte Testsuiten senken alle die Wahrscheinlichkeit, dass eine Umstellung in Etappen zum Feuerwehreinsatz wird. Die Migration von Bühler auf SAP S/4HANA zeigt, was disziplinierte Datenarbeit bringt: Die selektive Datenübernahme des Unternehmens reduzierte das operative Datenvolumen von ursprünglich mehreren Terabyte deutlich, was direkt bestimmte, wie viel In-Memory-Datenbankinfrastruktur überhaupt beschafft werden musste.

Governance, Veränderungsbegleitung und wie Erfolg tatsächlich aussieht

Eine Migration ohne Sponsor in der Geschäftsleitung verliert ihre Finanzierung meist in dem Moment, in dem die erste echte Hürde auftaucht, und die taucht bei jeder Migration auf. Ein Steuerungsgremium mit Führungskräften aus Geschäft und IT, das sich in festem Rhythmus trifft, gibt dem Projekt einen Ort, an dem Streit über den Umfang und Budgetüberschreitungen geklärt werden, bevor sie politisch werden.

Die Veränderungsbegleitung läuft parallel zur technischen Arbeit, nicht danach. Das heisst: Schulungen rund um den Pilot und jede Go-live-Etappe, ein Kommunikationsplan, der den betroffenen Teams sagt, was sich wann ändert, und ein gestaffelter Rollout an die Nutzenden, damit der Support nicht am ersten Tag Fragen aus der ganzen Organisation beantworten muss.

Messen Sie den Erfolg an wenigen konkreten Kennzahlen:

• Verfügbarkeit des Systems während und unmittelbar nach jeder Go-live-Etappe, verglichen mit dem Ausgangswert des Altsystems.

• Datenintegrität, belegt durch die Prüfungen der Datentreue, die während der Migration selbst aufgebaut wurden.

• Veränderung der Supportkosten, also ob Ticketmenge und Schweregrad nach der Migration tatsächlich sinken.

• Geschäftskennzahlen, die an die ursprüngliche Begründung der Migration geknüpft sind, sei das schnellere Auftragsabwicklung, geringeres Compliance-Risiko oder tiefere Lizenzkosten.

Nach der Migration zählt FinOps-Disziplin genauso viel. Cloud-Ausgaben, und zunehmend auch Kosten für KI-Arbeitslasten, neigen dazu, nach dem Go-live still nach oben zu kriechen, wenn niemand die laufende Kostenkontrolle verantwortet. Verteilen Sie diese Verantwortung, bevor die Migration endet, und nicht erst nach der ersten überraschenden Rechnung.

Beleg für den Erfolg gestaffelter Migrationen: zwei Schweizer Beispiele

Die Schweizer Bundesverwaltung hat ihre Migration auf SAP S/4HANA bewusst in Etappen umgesetzt und aus jeder Rollout-Phase gelernt, bevor der nächste Teil des Produktivsystems folgte. Bühler ging mit seiner selektiven Datenübernahme einen ähnlichen Weg und reduzierte das Datenvolumen, bevor die Infrastrukturinvestition auf den schlankeren Datenbestand ausgelegt wurde.

Einige Firmen wenden diese gestaffelte, von erfahrenen Fachleuten geführte Haltung auf Migrationen von Altsystemen an.

• Erfahrene Entwickler:innen bleiben im Idealfall von der ersten Beratung bis zur Übergabe im Projekt. So lassen sich Neuschreibungen mitten im Projekt vermeiden, wie sie bei Teamwechseln vorkommen.

• Unsere Arbeit an Legacy-Migration und Replatforming folgt genau der oben beschriebenen Abfolge aus Analyse, Pilot und Rollout.

• Die zugehörige Arbeit an Systemintegration und API-Entwicklung stützt die Abhängigkeitsanalyse und die Fassadenmuster, auf die Migrationen angewiesen sind.

Ein kompaktes Team mit wenigen Übergaben behält zwischen den Phasen meist mehr Kontext als grosse Teams mit häufigen Wechseln.

Ihre nächsten Schritte, bevor Sie ein Migrationsdatum festlegen

Bevor Sie einen Go-live-Termin setzen, sollten Sie Folgendes bereithaben:

1. Ein vollständiges Inventar von Anwendungen und Daten, inklusive der Fachanwendungen, die bisher niemand dokumentiert hat.

2. Einen benannten Sponsor in der Geschäftsleitung und ein Steuerungsgremium mit Entscheidungsmacht aus Geschäft und IT.

3. Einen abgesteckten Pilot für eine repräsentative, risikoarme Arbeitslast mit klaren Erfolgskriterien.

4. Eine Anbieterprüfung inklusive Datenschutzklauseln, bevor Sie irgendetwas unterschreiben.

5. Eine Pilotphase von 90 bis 180 Tagen mit einem verbindlichen Zeitpunkt für den Entscheid über Weitermachen oder Abbrechen.

6. Sicherheit, Recht, Datenverantwortliche, Betrieb und eine erfahrene technische Leitung ab dem ersten Tag an Bord, nicht erst nach dem Start des Piloten.

Planen Sie eine Reserve für mindestens eine ungeplante Abhängigkeit ein. Es gibt immer eine.

Wie Ampersand Labs eine gestaffelte Migration von Altsystemen begleitet

Ampersand Labs führt Migrationen so wie jedes andere Kundenprojekt: Erfahrene Entwickler:innen sind vom ersten Gespräch bis zur Übergabe dabei, damit nichts auf halbem Weg neu geschrieben werden muss, weil ein neues Team fremde Annahmen geerbt hat. Genau diese Kontinuität zählt, wenn sich eine Migration über Monate und mehrere Go-live-Etappen zieht. Wenn Sie abwägen, ob Lift-and-Shift, Replatforming oder ein vollständiges Strangler Pattern zu Ihren Systemen passt, klärt ein Erstgespräch das am schnellsten, bevor Budget gebunden wird. Wir unterstützen Sie auch bei der Arbeit an API und Systemintegration, auf die die meisten Migrationen angewiesen sind, sowie bei Softwarewartung und monatlichem Support, sobald das neue System läuft. Schauen Sie sich unsere Fallstudien an, um zu sehen, wie die Umsetzung in Etappen für andere Schweizer Organisationen funktioniert hat, und melden Sie sich anschliessend über unsere Seite zur Legacy-Migration, um ein Audit der Migrationsbereitschaft abzustecken.

Häufige Fragen

Warum skalieren alte Sicherheitssysteme 2026 nicht mehr?

Alte Sicherheitssysteme wurden in der Regel nicht für Datenverkehr in Cloud-Grössenordnung, moderne Authentifizierungsstandards oder die API-Anbindungen heutiger Anwendungen gebaut. Sie weiter zu flicken erhöht meist nur die Komplexität, ohne die zugrunde liegende Architektur zu verbessern. Deshalb ist das Sicherheitsrisiko einer der häufigsten Auslöser für den Start einer Migration.

Was ist eine Datenmigration aus Altsystemen?

Eine Datenmigration aus Altsystemen bezeichnet das Extrahieren, Umwandeln und Laden von Daten aus einem veralteten System in eine neue Plattform, wobei Richtigkeit und Vollständigkeit erhalten bleiben. Dafür müssen die Daten zuerst klassifiziert und Personendaten von betrieblichen Daten getrennt werden. Vor der Umstellung folgen Prüfungen der Datentreue, die alte und neue Datensätze vergleichen.

Wie übertragen Sie Daten aus einem Altsystem nach SAP?

Die Übertragung nach SAP, auch nach SAP S/4HANA, folgt in der Regel der Abfolge aus Analyse, Pilot und Rollout in Etappen, oft kombiniert mit einer selektiven Datenübernahme, die nur die operativ noch benötigten Daten mitnimmt. Bühler ist genau so vorgegangen und hat das operative Datenvolumen deutlich reduziert, bevor die neue Infrastruktur skaliert wurde.

Wie viele Unternehmen setzen noch Altsysteme ein?

Eine einzelne allgemeingültige Zahl gibt es nicht, denn «Altsystem» reicht vom Jahrzehnte alten Grossrechner bis zur fünfjährigen Anwendung, deren Support bald ausläuft. Branchenübergreifend gilt jedoch: Die meisten mittelgrossen Unternehmen und öffentlichen Stellen betreiben mindestens ein System, das alt genug ist, um Risiken bei Integration, Sicherheit oder Compliance zu schaffen. Genau darum bleibt die Planung einer Migration in Etappen relevant, unabhängig von der genauen Verbreitung.

Was kostet eine Migration von Altsystemen bei Ampersand Labs?

Der Preis hängt vom Umfang der Migration ab, also davon, ob es sich um ein vollständiges Replatforming, eine Systemmigration oder ein gezieltes Integrationsprojekt handelt. Die aktuellen Ansätze finden Sie direkt auf der Preisseite von Ampersand. Am schnellsten kommen Sie über ein Erstgespräch zu einer Schätzung für Ihre konkreten Systeme.

Empfohlen

• Die Mitte: Über 600 Websites einer Schweizer Partei aus einem einzigen System.

• Arthouse Kinos: Neue Website und Ticketshop für die bekanntesten Kinos in Zürich.

• Repa Immobiliare: Ein Immobilienportfolio weg vom Papier, mit Software, die nie online geht.