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 Tools.

Was dabei gerne vergessen wird: Am Tag nach der Migration können viele direkte interne Links kaputt sein.

Dazu können Lesezeichen, in Slack geteilte Links und Verweise in Onboarding-Dokumenten, E-Mail-Signaturen, Confluence-Seiten oder Jira-Beschreibungen gehören.

Warum das so wehtut

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 Lesezeichen 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 technische Adressen, die sich ändern können, wenn Inhalte verschoben, Systeme umstrukturiert oder Tools ersetzt werden.

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 namens /roadmap zeigt auf die aktuelle URL der Roadmap. Wenn sich diese ändert, wird der Shortcut einmal aktualisiert. In Lora öffnet man ihn mit short, Leertaste und roadmap.

Am einfachsten baust du diese Ebene vor der Migration auf und ersetzt dabei die häufig genutzten direkten Links.

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: /wiki, /roadmap, /onboarding, /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. /wiki kann vorher auf Confluence und danach auf Notion zeigen. Links, die über diesen Shortcut geteilt wurden, behalten dieselbe Lora-Adresse; direkte Links brauchen weiterhin eine eigene Migrationslösung.

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

Am besten führst du Shortcuts vor einer Migration ein, sonst 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.

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

Bei Shortcuts passt ein Admin nur das Ziel einmal an. Die Namen und die geteilten Links bleiben für alle gültig.