Dein Team in einer Woche auf ein Tool umstellen

Drei oder vier Tools in eines zu konsolidieren klingt nach einem Projekt, das ein Quartal dauert. Muss es nicht. Der Großteil der eigentlichen Arbeit — Daten exportieren, Struktur neu aufbauen, Gewohnheiten umtrainieren — passt in eine fokussierte Woche, wenn du sie richtig ordnest. Hier ist der Fahrplan, dem wir mit jedem Team folgen würden, mit Proman als Beispiel — aber die Reihenfolge gilt für jedes Tool, zu dem du wechselst.

Tag 1: Prüfe deinen Stack

Bevor du irgendetwas anfasst, schreibe auf, was du tatsächlich hast:

Jedes Tool, das gerade genutzt wird, einschließlich derer, die niemand offiziell genehmigt hat (dieses Schatten-Trello-Board, das jemand betreibt).
Jedes aktive Projekt, und welche davon wirklich aktiv sind vs. ruhend. Sei ehrlich — ein Projekt ohne Aktivität seit 60 Tagen braucht keine saubere Migration, es braucht ein Archiv.
Jede Integration, die derzeit zwischen Tools verdrahtet ist (Slack-Benachrichtigungen von deinem PM-Tool, Zeiteinträge, die ein Rechnungstool speisen usw.) — du musst jede davon neu aufbauen oder ersetzen.
Wer was besitzt — wer ist Admin bei jedem Tool, wer hat Abrechnungszugriff, wer muss die Kündigung später genehmigen.

Das Ergebnis von Tag 1 sollte eine kurze Liste sein: welche Projekte migrieren, welche unverändert archiviert werden und welche Integrationen einen Ersatz brauchen. Diesen Schritt zu überspringen ist die größte Einzelursache für Migrationen, die sich über Monate hinziehen — am Ende migrierst du veraltete, halbfertige Arbeit direkt neben dem, was wirklich zählt.

Tag 2: Projekte exportieren und importieren

Beginne nur mit deinen aktiven Projekten — der Liste von Tag 1.

Immer zuerst exportieren. Die meisten PM-Tools bieten einen CSV- oder JSON-Export von Aufgaben, Projekten und Kommentaren. Zieh das, bevor du irgendetwas anderes tust, selbst wenn du die Rohdatei am Ende nicht nutzt — sie ist dein Sicherheitsnetz.
Migriere zuerst ein Projekt. Importiere nicht alles auf einmal in einem Batch. Wähle dein aktivstes Projekt, rekonstruiere seine Struktur manuell (Spalten, Prioritäten, Fälligkeitsdaten) und nutze es als Vorlage für den Rest. Das bringt strukturelle Unstimmigkeiten früh ans Licht — ein benutzerdefiniertes Feld oder eine Workflow-Stufe, die nicht sauber passt — während der Schaden auf ein Projekt begrenzt ist, nicht auf zwölf.
Bewahre Kontext, nicht nur Aufgaben. Aufgabentitel und Fälligkeitsdaten lassen sich leicht importieren. Kommentarverlauf und Dateianhänge oft nicht. Entscheide vorab, ob diese Historie umziehen muss oder ob das alte Tool zur Referenz im Nur-Lese-Zugriff bleibt (siehe Tag 5).
Weise unterwegs neu zu. Importiere Aufgaben nicht unzugewiesen, um es später zu klären — weise Verantwortliche während des Imports zu, solange du dich noch erinnerst, wer was gemacht hat.

Tag 3: Chat-Umstieg — Archivieren, nicht löschen

Chat-Migrationen scheitern aus einem vorhersehbaren Grund: Teams versuchen einen harten Umstieg am ersten Tag, und alle nutzen still weiter den alten Kanal, weil das Gewohnheit ist.

Richte zuerst die neuen Chat-Bereiche ein, die deine meistgenutzten Kanäle spiegeln (allgemein, pro Projekt, pro Team).
Kündige einen konkreten Umstiegsmoment an — nicht „irgendwann diese Woche“, sondern eine konkrete Zeit. Uneindeutigkeit verursacht gespaltene Nutzung.
Archiviere die alten Kanäle, lösche sie nicht. Du wirst Wochen später in der alten Chat-Historie nach Kontext suchen müssen. Archivierung hält sie durchsuchbar und schreibgeschützt, ohne mit den neuen Kanälen um Aufmerksamkeit zu konkurrieren.
Umleiten, nicht nörgeln. Eine angepinnte Nachricht im alten Kanal, die auf den neuen verweist, plus eine Bot-Nachricht, falls dein altes Tool das unterstützt, bewirkt mehr als wiederholte Erinnerungen.

Tag 4: Zeiterfassung und Vorlagen

Das ist der Tag, den Teams am häufigsten überspringen, und der Grund, warum alte Gewohnheiten einen Monat später wieder einschleichen.

Richte zuerst Zeiterfassungskategorien ein — spiegle die Abrechnungs- oder Reporting-Kategorien, die du zuvor genutzt hast, damit historische Vergleiche weiterhin Sinn ergeben.
Baue Vorlagen für wiederkehrende Projekttypen. Wenn du wiederholt dieselbe Art von Auftrag durchführst (eine monatliche Pauschale, ein Standard-Sprint), baue die Board-/Aufgabenvorlage einmal, damit jedes neue Projekt konsistent startet.
Migriere nur die Zeitdaten des aktuellen Abrechnungszeitraums, falls dein altes Tool Exporte unterstützte. Ältere Zeithistorie kann meist zur Referenz im alten Tool bleiben, statt neu erfasst zu werden.
Teste den Rechnungsweg von Anfang bis Ende, bevor du dich für eine echte Kundenrechnung darauf verlässt. Erfasse einen Test-Zeiteintrag, erstelle eine Testrechnung, bestätige, dass die Zahlen deinen Erwartungen entsprechen.

Tag 5: Alte Tools stilllegen

Halte die alten Tools für ein definiertes Zeitfenster im Nur-Lese-Modus (2–4 Wochen sind üblich), statt sofort zu kündigen. Das gibt dir ein Sicherheitsnetz für alles, was du beim Export übersehen hast.
Setze jetzt ein konkretes Kündigungsdatum in den Kalender, nicht „sobald wir sicher sind“. Eine unbefristete Nur-Lese-Phase wird tendenziell dauerhaft, und am Ende zahlst du unbegrenzt für den alten und den neuen Stack.
Bestätige, dass jede Integration entweder migriert oder ausdrücklich stillgelegt wurde. Eine baumelnde Zapier-Verbindung, die dich noch belastet, oder ein Slack-Webhook, der noch in einen Kanal feuert, den niemand liest, ist die Art von Ding, das monatelang unbemerkt weiterläuft.
Kündige zum festgelegten Datum. Das ist der Schritt, der die Kostenersparnis tatsächlich realisiert — alles davor ist Vorbereitung.

Häufige Fallstricke

Zwei Systeme zu lange parallel betreiben. Der mit Abstand größte Fehlermodus. Wenn sowohl das alte als auch das neue Tool länger als ein paar Wochen „live“ sind, wird ein Teil des Teams standardmäßig das nutzen, mit dem er sich wohler fühlt, und am Ende hast du fragmentierte, unsynchronisierte Daten in beiden.

Veraltete Projekte migrieren. Gib einem toten Projekt nicht denselben Migrationsaufwand wie einem aktiven. Wenn niemand es seit zwei Monaten angefasst hat, archiviere es im alten Tool und lass es dort — verbring nicht Tag 2 damit, sein Board neu aufzubauen.

Kein einzelner Verantwortlicher für den Umstieg. Migrationen, die „Verantwortung von allen“ sind, werden zur Verantwortung von niemandem. Weise eine Person zu, die die Woche vorantreibt, die tagesgenauen Entscheidungen trifft und diejenige ist, die die alten Abonnements an Tag 5 tatsächlich kündigt.

Die Testrechnung überspringen. Fehler bei Zeiterfassung und Rechnungsstellung sind unsichtbar, bis sie eine echte Kundenrechnung betreffen. Teste den gesamten Weg mit Testdaten, bevor die erste echte rausgeht.

Eine Woche reicht aus, um das sauber zu erledigen, wenn du es richtig ordnest — prüfen vor dem Migrieren, ein Projekt vor allen, archivieren vor löschen und ein festes Datum, bevor du tatsächlich irgendetwas kündigst. Das Tool, zu dem du wechselst, ist weniger wichtig, als diese fünf Dinge in der richtigen Reihenfolge zu tun.