Bei einem Softwarewechsel sollten nur laufende und kürzlich abgeschlossene Projekte migriert werden; ältere Bestände bleiben in einem lesenden Archiv des Altsystems oder als Export. Der Versuch, die vollständige Historie zu übernehmen, verlängert das Projekt erheblich und überträgt Datenqualitätsprobleme in das neue System.
Der entscheidende Umfangsentscheid
Die erste und folgenreichste Frage lautet nicht «wie migrieren wir», sondern «was migrieren wir». Der Reflex ist, alles mitzunehmen — das wirkt sicher und ist meist der teuerste Weg.
| Datenbestand | Empfehlung | Begründung |
|---|---|---|
| Laufende Projekte | Vollständig migrieren | Werden aktiv gebraucht |
| Abschluss in den letzten 12 Monaten | Migrieren oder als Export ablegen | Referenz für laufende Arbeit |
| Ältere abgeschlossene Projekte | Export oder lesendes Altsystem | Werden selten aufgerufen |
| Vorlagen und Konfiguration | Neu aufbauen, nicht übernehmen | Gute Gelegenheit zum Aufräumen |
| Aufgabenhistorie und Kommentare | Selektiv | Grosser Aufwand, geringer Nutzen |
Die vierte Zeile ist die wichtigste. Vorlagen und Konfiguration eines Systems, das über Jahre gewachsen ist, enthalten Entscheidungen, die niemand mehr begründen kann. Sie zu übertragen bedeutet, den Ballast in das neue System zu tragen — mitsamt der Frage, warum ein bestimmtes Feld existiert, die dann noch weitere Jahre unbeantwortet bleibt.
Datenqualität vor der Migration prüfen
Jedes gewachsene System enthält Datenqualitätsprobleme: doppelte Projekte, verwaiste Aufgaben, Personen, die längst ausgetreten sind, Projekte ohne Abschluss aus dem Jahr 2019. Diese Probleme wandern bei einer unbereinigten Migration mit — und im neuen System sind sie schwerer zu erkennen, weil niemand mehr weiss, was Altlast ist.
Die Bereinigung gehört vor die Migration, nicht danach. Sie ist unbeliebt, weil sie Aufwand ohne sichtbares Ergebnis bedeutet, und sie ist der Unterschied zwischen einem sauberen Neustart und einem Umzug samt Keller.
Migrieren Sie nur Projekte, die in den letzten zwölf Monaten Aktivität hatten. Alles andere geht als Export ins Archiv. In der Praxis reduziert das den Migrationsumfang oft um mehr als die Hälfte — bei kaum spürbarem Verlust.
Ablauf
- 01Umfang festlegenWas wird migriert, was archiviert, was verworfen — als Entscheid dokumentiert, nicht als Annahme.
- 02Zielstruktur aufbauenProjektstruktur, Rollen, Rechte und Vorlagen im neuen System neu konzipieren, bevor Daten fliessen.
- 03Abbildungsregeln definierenWelches Feld wird zu welchem, was passiert mit Feldern ohne Entsprechung? Diese Liste ist das Kernstück.
- 04Probemigration mit FachprüfungMindestens zweimal vollständig, jeweils mit inhaltlicher Kontrolle durch die künftigen Nutzer.
- 05Stichtag festlegenAb wann wird im Altsystem nichts mehr erfasst? Ohne klaren Schnitt entsteht Doppelpflege.
- 06Umstellung und Altsystem lesendDas Alte bleibt eine begrenzte Zeit lesend verfügbar — das nimmt der Umstellung den Druck.
Der vierte Schritt ist der, an dem am häufigsten gespart wird. Eine Probemigration, deren Resultat niemand fachlich kontrolliert hat, belegt nur, dass der technische Vorgang durchläuft — nicht, dass die Daten danach richtig sind.
Doppelbetrieb vermeiden
Der häufigste Fehler ist der weiche Übergang: Beide Systeme bleiben eine Weile aktiv, «damit sich alle in Ruhe umstellen können». Das Ergebnis ist verlässlich, dass Teile der Organisation im Alten bleiben, Informationen sich aufteilen und nach drei Monaten niemand weiss, wo der aktuelle Stand steht.
Wirksamer ist ein harter Stichtag für die Erfassung, kombiniert mit einem lesenden Zugriff auf das Alte über mehrere Monate. Damit ist klar, wo gearbeitet wird, und die Sicherheit, dass nichts verloren geht, bleibt trotzdem bestehen.
Den Wechsel für die Bereinigung nutzen
Ein Systemwechsel ist der einzige Moment, in dem eine Organisation bereit ist, ihre Arbeitsweise zu hinterfragen. Diese Gelegenheit ist begrenzt — nach der Einführung kehrt die Bereitschaft für Jahre nicht zurück.
Nutzen Sie sie für die Fragen, die sonst nie gestellt werden: Brauchen wir wirklich fünf Projektstatus? Wer liest die vier Standardberichte? Warum gibt es zwei Wege, eine Aufgabe anzulegen? Ein Wechsel, der die alte Arbeitsweise eins zu eins abbildet, hat den grösseren Teil seines möglichen Nutzens verschenkt.
Häufige Fragen
- Was sollte man bei einem Softwarewechsel migrieren?
- Laufende Projekte vollständig, in den letzten zwölf Monaten abgeschlossene als Export oder Migration, ältere Bestände als Archiv im Altsystem. Vorlagen und Konfiguration sollten neu aufgebaut statt übernommen werden.
- Wie vermeidet man Doppelbetrieb beim Toolwechsel?
- Mit einem harten Stichtag für die Erfassung, kombiniert mit lesendem Zugriff auf das Altsystem über mehrere Monate. Ein weicher Übergang führt verlässlich dazu, dass Teile der Organisation im Alten bleiben.
- Wie oft sollte eine Probemigration durchgeführt werden?
- Mindestens zweimal vollständig, jeweils mit inhaltlicher Prüfung durch die künftigen Nutzer. Eine Probemigration ohne fachliche Kontrolle belegt nur, dass der technische Vorgang durchläuft.