Vor dem Tool-Wechsel: Diese 6 Dinge solltest du sichern

Die Exportgrenzen unterscheiden sich deutlich. Airtable exportiert CSV-Dateien ansichtsweise; Filter können Datensätze ausblenden, Kommentare fehlen und Anhänge erscheinen zunächst als zeitlich begrenzte Links. Slack-Exporte hängen von Tarif und Exportart ab und enthalten häufig Dateilinks statt der Dateien. Notion kann Seiten und hochgeladene Dateien exportieren, schließt aber Inhalte aus, auf die die exportierende Person keinen Zugriff hat, und weist darauf hin, dass sich ein Workspace nicht einfach durch erneutes Hochladen des Exports wiederherstellen lässt.

Warum „Export vorhanden“ nicht als Freigabe reicht

Ein Tool-Wechsel ist keine einzelne Dateiübertragung. Er betrifft Inhalte, Beziehungen zwischen Datensätzen, Zugriffsmodelle und Abläufe. Die offizielle Airtable-Dokumentation zeigt beispielsweise, dass ein gefilterter View nicht den vollständigen Tabellenbestand abbildet. Bei Slack unterscheiden sich öffentliche Kanäle, private Unterhaltungen und Dateien im Exportumfang. Und bei Notion hängt die Vollständigkeit auch von den Rechten der exportierenden Person ab.

Die praktische Konsequenz: Lege vor dem Export fest, welche Informationen und Funktionen nach dem Wechsel noch nutzbar sein müssen. Erst danach kannst du prüfen, ob der Export dieses Ziel tatsächlich erfüllt.

Die sechs Sicherungen vor dem Tool-Wechsel

1. Datenbestand und Exportumfang

Erstelle zuerst ein Inventar der wichtigen Objekte: etwa Kunden, Projekte, Aufgaben, Dokumente, Nachrichten, Formulare und benutzerdefinierte Felder. Notiere pro Objekt, wer verantwortlich ist, wie viele Einträge erwartet werden und welches Exportformat verfügbar ist.

Prüfe dabei Filter, archivierte Bereiche, Papierkörbe, verknüpfte Datensätze und Zeiträume. Bei Google Takeout kann das Archiv laut Google-Hilfe Änderungen auslassen, die zwischen Exportanfrage und Archiverstellung erfolgen. Plane deshalb einen klaren Stichtag und – falls das Tool es unterstützt – einen letzten Delta-Export für die Änderungen seit dem ersten Lauf.

Abnahmebeleg: Eine Liste der erwarteten Objekte und Mengen, abgeglichen mit dem geöffneten Export.

2. Dateien, Anhänge, Kommentare und Versionen

Sichere nicht nur Zeilen und Textfelder. Lade geschäftskritische Anhänge als echte Dateien herunter und prüfe, ob Dateiname, Zuordnung und Öffnen nach dem Wechsel erhalten bleiben. In Airtable enthält ein CSV-Export bei Anhängen Dateinamen und URLs; diese Download-URLs laufen laut Airtable-Hilfe nach kurzer Zeit ab. Slack weist darauf hin, dass viele Exporte Dateilinks statt Dateien enthalten.

Kommentare, Versionsstände, eingebettete Inhalte und Vorschaudaten brauchen eine eigene Prüfung. Wenn das Zieltool sie nicht übernehmen kann, entscheide bewusst, ob ein lesbares Archiv genügt.

Abnahmebeleg: Stichproben aus alten und neuen Datensätzen, einschließlich Anhängen, Umlauten, Datumsfeldern und Verknüpfungen.

3. Nutzer, Rollen und Freigaben

Exportiere oder dokumentiere aktive Nutzer, Gäste, Gruppen, Administratoren, Servicekonten und Freigaben. Ordne anschließend jede bisherige Rolle einer Rolle im Zieltool zu. Übernimm Berechtigungen nicht blind: Eine Migration kann Rechte anders abbilden oder gar nicht mitnehmen. Google dokumentiert etwa, dass bei einer bestimmten Outlook-zu-Google-Workspace-Migration Freigaben gemeinsamer Kalender nicht übernommen werden. Atlassian beschreibt zudem, wie Gruppennamenskonflikte zu falschem Zugriff führen können.

Teste deshalb mit repräsentativen Konten: Kann eine normale Person nur das sehen und ändern, was sie wirklich benötigt? Gibt es mindestens zwei klar benannte Administratoren für den Übergang?

Abnahmebeleg: Rollenmatrix plus erfolgreiche Anmeldung und Rechteprüfung mit Testkonten.

4. Integrationen, Automationen und Einstellungen

Liste Webhooks, API-Verbindungen, SSO, Kalender- und E-Mail-Anbindungen, Formulare, Vorlagen, Benachrichtigungen, Dashboards und wiederkehrende Automationen auf. Dokumentiere jeweils Zweck, verantwortliche Person, Auslöser, Ziel, verwendetes Konto und Wiederanlauf-Schritt. Zugangsschlüssel gehören dabei in einen geeigneten Secret-Speicher, nicht in die Checkliste.

IDs und Endpunkte können sich beim Wechsel ändern. Atlassian weist in seiner Migrations-Checkliste ausdrücklich darauf hin, dass veränderte Objekt-IDs externe Integrationen nach der Migration beeinträchtigen können. Führe deshalb jede kritische Automation kontrolliert im Zielsystem aus und prüfe ihr Ergebnis.

Abnahmebeleg: Integrationsregister mit Status „ersetzt“, „neu verbunden“ oder „bewusst abgeschaltet“ und einem dokumentierten Funktionstest.

5. Verträge, Abrechnung und Aufbewahrung

Archiviere Vertrag, Auftragsverarbeitungsvereinbarung, Rechnungen, Kündigungsfrist, Verlängerungsdatum und dokumentierte Aufbewahrungs- oder Löschregeln. Kläre, wer die Kündigung auslösen darf und wann der Anbieter Daten oder Zugänge endgültig entfernt.

Dieser Schritt ist keine pauschale Rechtsberatung. Bei personenbezogenen, steuerlich relevanten oder regulierten Daten müssen die zuständigen Personen die konkreten Pflichten für Unternehmen, Branche und Standort prüfen.

Abnahmebeleg: Ein bestätigter Kündigungstermin, ein Verantwortlicher und ein festgehaltener Aufbewahrungsort für benötigte Unterlagen.

6. Testmigration, Schreibstopp und Rückweg

Migriere zuerst einen kleinen, aber repräsentativen Bereich. Die Atlassian-Migrationsanleitung empfiehlt eine Testmigration vor dem produktiven Lauf und eine Sicherung von Quell- und gegebenenfalls bereits befülltem Zielsystem. Für den eigentlichen Wechsel legst du einen Zeitpunkt fest, ab dem im alten Tool nichts mehr geändert wird. So bleibt klar, welcher Stand maßgeblich ist.

Definiere außerdem den Rückweg: Wie lange bleibt das alte System erreichbar? Wer entscheidet über einen Abbruch? Welche Daten werden bei einem Rückwechsel wiederhergestellt? NIST beschreibt Notfallplanung als abgestimmte Kombination aus Plänen, Verfahren und technischen Maßnahmen zur Wiederherstellung von Systemen, Betrieb und Daten.

Abnahmebeleg: Erfolgreiche Testmigration, festgehaltener Schreibstopp, benannte Abbruchentscheidung und getesteter Wiederherstellungsschritt.

Ein kurzer Abnahmetest vor der Kündigung

Öffne nicht nur die Exportdatei. Spiele einen typischen Arbeitsablauf im Zieltool durch:

• Finde je einen älteren und einen aktuellen Datensatz.
• Öffne einen Anhang und prüfe seine Zuordnung.
• Kontrolliere Verknüpfungen, Umlaute, Datumswerte und Zeitzonen.
• Melde dich mit einem normalen Nutzerkonto an und prüfe Lese- und Schreibrechte.
• Starte eine kritische Automation zunächst ohne externe Nebenwirkungen.
• Vergleiche die erwarteten Mengen mit Quelle, Export und Ziel.
• Halte Abweichungen, Entscheidung und verantwortliche Person schriftlich fest.

Ein grüner Test bedeutet nicht, dass jede Randbedingung bewiesen ist. Er zeigt aber, ob die für dein Team wichtigsten Inhalte und Abläufe unter realistischen Bedingungen funktionieren.

Wann du das alte Tool kündigen kannst

Die Kündigung ist erst sinnvoll, wenn alle sechs Bereiche einen nachvollziehbaren Abnahmebeleg haben, die letzte Änderungssicherung abgeschlossen ist und ein Verantwortlicher den Rückweg kennt. Bleibt bei Daten, Dateien, Rechten oder kritischen Automationen eine Lücke, sollte das alte System – soweit Vertrag und Produkt es zulassen – vorerst nur lesbar bleiben.

Das Ziel ist nicht ein perfektes Archiv jeder Oberfläche. Das Ziel ist ein kontrollierter Übergang: Geschäftskritische Informationen bleiben auffindbar, berechtigte Personen können weiterarbeiten, und ein Fehler zwingt das Team nicht zu improvisieren.