Intranet-Migration ohne Tränen

Confluence zu Notion. Altes SharePoint zu neuem SharePoint. Google Sites zu SharePoint. Die Gründe sind meistens gut — bessere Funktionen, niedrigere Kosten, einheitlichere Tool-Landschaft.

Was dabei gerne vergessen wird: Am Tag nach der Migration sind sämtliche internen Links kaputt.

Jeder Bookmark, den sich jemand über Monate gesetzt hat. Jeder Link, der in einer Slack-Nachricht geteilt wurde. Jeder Link in einem Onboarding-Dokument. Jeder Link in einer E-Mail-Signatur, einer Confluence-Seite, einer Jira-Beschreibung. Alles 404.

Warum das so wehtut

Links sind die Infrastruktur, die niemand sieht, bis alles kaputt ist.

Leute finden nichts mehr. Die ersten Tage nach einer Migration sind geprägt von “Wo ist jetzt…?”-Fragen in Slack und Teams. Die IT wird überflutet mit Anfragen. Die Produktivität sinkt für Tage, manchmal Wochen.

Dazu kommt: Das neue System wirkt auf Anhieb kaputt. Leute hatten gerade angefangen, sich im alten System zurechtzufinden. Jetzt müssen sie von vorne anfangen, und die erste Erfahrung mit dem neuen System ist: “Mein Bookmark geht nicht mehr.”

Manche Teams bauen sich dann Workarounds, die nie wieder verschwinden. Ein Google Doc mit “den wichtigsten Links im neuen System.” Eine gepinnte Slack-Nachricht. Genau die Art von Behelfslösung, die man mit der Migration eigentlich loswerden wollte.

Was die meisten Teams machen (und warum es nicht reicht)

Die übliche Lösung: Redirects einrichten. Funktioniert technisch, hat aber Grenzen.

Du musst jede alte URL kennen und mappen können. Bei hunderten SharePoint-Seiten ist das viel Arbeit, und automatisierte Redirect-Mappings decken selten alles ab.

Außerdem sind Redirects provisorisch. Irgendwann schaltest du die alte Infrastruktur ab, und die Redirects verschwinden mit ihr.

Und Redirects lösen nur diese Migration. Beim nächsten Tool-Wechsel passiert das Ganze wieder.

Ein anderer Ansatz: Die URL vom Namen trennen

Interne Links zeigen auf URLs, also auf technische Adressen, die sich ständig ändern. Notion-Seite umbenannt? Neue URL. SharePoint-Ordner verschoben? Neue URL. Tool gewechselt? Alle URLs weg.

Was sich nicht ändern sollte: der Name, unter dem Mitarbeiter eine Ressource kennen. “Roadmap” bleibt “Roadmap”, egal ob sie in Confluence, Notion oder einem Google Doc lebt.

Die Lösung ist eine Abstraktionsschicht zwischen dem Namen und der URL. Ein Shortcut wie short/roadmap zeigt auf die aktuelle URL der Roadmap. Wenn die URL sich ändert (weil das Tool gewechselt wurde), wird der Shortcut einmal aktualisiert. Alle, die short/roadmap verwenden, landen weiterhin an der richtigen Stelle.

Trotzdem macht es fast niemand vorher, weil der Schmerz erst nach der Migration kommt.

Wie du dich auf eine Migration vorbereitest

Wenn du weißt, dass ein Tool-Wechsel ansteht (oder auch nur möglich ist), kannst du jetzt schon die Grundlage legen.

Fang mit den 20 bis 30 meistgenutzten internen Ressourcen an. Roadmap, Wiki-Startseite, HR-Formulare, Onboarding-Docs, Brand Guidelines, Architektur-Dokumentation. Frag im Team, welche Links sie täglich oder wöchentlich benutzen.

Dann erstellst du für jede Ressource einen Shortcut mit einem lesbaren Namen. short/wiki, short/roadmap, short/onboarding, short/brand. Teile sie im Team und gewöhne die Leute daran, Shortcuts statt direkter URLs zu verwenden.

Wenn die Migration kommt, aktualisierst du die URLs hinter den Shortcuts. Das Team merkt davon im besten Fall gar nichts. short/wiki hat vorher auf Confluence gezeigt, jetzt zeigt es auf Notion. Der Name ist derselbe. Kein Bookmark ist kaputt. Kein geteilter Link in Slack führt ins Leere.

Was das nicht löst

Wenn jemand einen direkten Confluence-Link in einem Jira-Ticket hinterlegt hat, ist dieser Link nach der Migration trotzdem kaputt. Shortcuts schützen nur die Links, die als Shortcuts geteilt wurden. Je mehr das Team Shortcuts statt direkter URLs verwendet, desto besser ist es gegen Migrationen geschützt.

Und Shortcuts helfen nicht beim eigentlichen Migrationsaufwand — die Inhalte müssen trotzdem übertragen, überprüft und angepasst werden. Es geht nur um die Navigationsebene: dass die Leute die Sachen wiederfinden, nachdem sie umgezogen wurden.

Wann der richtige Zeitpunkt ist

Der beste Zeitpunkt, um Shortcuts einzuführen, ist vor einer Migration. Der zweitbeste ist jetzt, auch wenn keine Migration geplant ist. Denn Tool-Wechsel passieren häufiger als man denkt. Und selbst ohne Migration ändert sich ständig etwas: Notion-Seiten werden umstrukturiert, Google-Drive-Ordner werden verschoben, jemand benennt ein Projekt um.

Jeder dieser kleinen Änderungen bricht irgendwo einen Link. Meistens merkt es niemand sofort. Aber irgendwann klickt jemand auf einen Bookmark und landet im Nirgendwo.

Shortcuts absorbieren solche Änderungen leise. Man merkt nicht, dass sie funktionieren, bis man feststellt, dass nichts kaputtgegangen ist.