Irgendwann kostet Confluence doppelt: mehr Lizenzkosten, je größer Ihr Team wird, und mehr Zeit, weil Wissen immer schwerer zu vertrauen ist. Seiten werden nicht gepflegt, Strukturen brechen, und irgendwann weiß niemand mehr, was eigentlich noch die „richtige Quelle“ ist.
Und wenn Sie ohnehin schon täglich in Microsoft 365 arbeiten, stellt sich die Frage ganz automatisch: Warum Wissen in einem separaten System behalten, wenn SharePoint sowieso schon da ist?
Meist beginnt genau dann die Migrationsdiskussion. Nicht weil SharePoint gerade „modern“ ist, sondern weil Sie ein System für Ihre Mitarbeitenden wollen und einen Ort, an dem Wissen nicht verloren geht.
Aber genau hier machen die meisten Migrationen einen entscheidenden Fehler: Sie verschieben Seiten – und verlieren Makros. Und mit den Makros verlieren sie die Art, wie Menschen arbeiten. Wenn Sie ohne Makro-Plan migrieren, verschieben Sie nicht einfach Inhalte. Sie verschieben einen Stapel Seiten… und verlieren die Erfahrung, die Confluence überhaupt erst nutzbar gemacht hat.
Dieser Guide zeigt, wie Sie Confluence nach SharePoint migrieren, ohne das zu verlieren, worauf Ihre Nutzer am meisten angewiesen sind – insbesondere Makros – und wie Sie mit SharePoint plus moderner Wiki-Schicht das gleiche Wissens-Erlebnis (oft sogar besser) wieder aufbauen.
Confluence nach SharePoint migrieren – Das echte Risiko: Wenn Confluence-Makros verschwinden, verschwindet Vertrauen
Confluence-Makros sind keine Deko. Sie sind der Grund, warum Teams Ordnung halten. Teams nutzen Makros, um:
- Seiten zu navigieren (Table of Contents)
- Wissensstrukturen aufzubauen (Children Display)
- Inhalte wiederzuverwenden (Include Page)
- Dokumentation konsistent zu halten (Page Properties)
- Status und Ownership sichtbar zu machen
- Tickets und Arbeit zu verbinden (Jira-Makros)
- Lange Seiten lesbar zu machen (Expand)
Wenn diese Makros verschwinden, sagen Leute nicht: „Oh nein, das Makro fehlt.“
Sie sagen:
„Dieses Intranet ist verwirrend.“
„Ich finde nichts.“
„Ich frage lieber jemanden.“
„Ich vertraue dem nicht, was ich lese.“
Und sobald das passiert, bricht die Akzeptanz weg – egal wie „sauber“ die Migration technisch war.
Denn dann passiert genau das, was Sie wahrscheinlich schon aus Confluence kennen:
- Jeder erstellt Seiten anders
- Makros werden uneinheitlich verwendet
- Navigation wächst zufällig
- Niemand weiß, was noch gültig ist
- Ownership verschwindet
- Suche wird zum Ratespiel
Das eigentliche Ziel ist also nicht „Confluence nach SharePoint verschieben“. Das eigentliche Ziel ist: Confluence nach SharePoint migrieren, ohne das Nutzer-Erlebnis zu verlieren, das Ihre Teams an Confluence schätzen.
Confluence-Makros-zu-SharePoint-Mapping
Unten sehen Sie ein praxisnahes Mapping, das in echten Intranet-Migrationen funktioniert – nicht nur in der Theorie.
| Confluence Makro / Funktion | Wofür Nutzer es brauchen | SharePoint-Äquivalent | Was es langfristig stabil macht |
| Table of Contents | Seitennavigation | Seitenbereiche + Anker / TOC-Webpart | Templates + konsistente Überschriften |
| Children Display | Hierarchie / Struktur | Hub-Navigation + Seitenstruktur | Wiki-Baumstruktur |
| Labels | Auffindbarkeit | Managed Metadata | Microsoft Tag Cloud + beliebte Tags |
| Page Properties / Report | strukturierte Dokumentation | Listen + Metadaten-Views | Templates + Pflichtfelder |
| Status Makro | Sichtbarkeit Draft/Approved | Auswahlspalten + Formatierung | Governance + Owners |
| Include Page | Wiederverwendung | Webparts + Verlinkung | Single-Source-of-Truth-Blöcke |
| Expand Makro | bessere Scanbarkeit | einklappbare Abschnitte | SPFx Webpart |
| Mentions / Ownership | Vertrauen & Verantwortlichkeit | Autoren + Versionshistorie | Contributors + sichtbares Ownership |
Das ist der Unterschied zwischen „Inhalte migrieren“ und „ein nutzbares Wissenssystem migrieren“.
Der Migrationsplan: 7 Schritte, die Ihre Makros schützen (und Ihre Akzeptanz)
Schritt 1: Wählen Sie die Spaces, die wirklich zählen (und starten Sie damit)
Starten Sie nicht mit „was am einfachsten ist“. Starten Sie mit dem, was am meisten genutzt wird.
Wählen Sie:
- Spaces mit täglichem Traffic
- Spaces mit hoher Makro-Nutzung
- Spaces, die Onboarding, Policies, Operations, IT, HR betreffen
Diese Spaces entscheiden, ob Mitarbeitende dem neuen Intranet vertrauen.
Schneller Praxis-Tipp: Starten Sie mit einem „High-Impact“-Space (z. B. HR-Richtlinien oder Operations-Handbuch). Wenn Mitarbeitende genau dort Inhalte schnell finden und ihnen vertrauen, entsteht Adoption-Momentum ganz automatisch.
Häufiger Fehler: Zuerst Low-Usage-Spaces migrieren, weil sie „cleaner“ sind. Sieht in Projektplänen gut aus, erzeugt aber keinen Trust und beweist keinen Mehrwert.
Schritt 2: Erstellen Sie ein Makro-Inventar (nicht raten)
Viele Teams unterschätzen die Makro-Nutzung, weil sie Makros nicht als Funktion sehen – bis sie fehlen.
Inventarisieren Sie:
- Include Page / Excerpt Include
- Page Properties / Report
- Labels
- Children Display
- TOC
- Status-Makros
Das ist Ihre Risiko-Landkarte für die Migration.
Schneller Praxis-Tipp: Starten Sie mit den Top 3 Makros in Ihren wichtigsten Spaces und entscheiden Sie, wie sie ersetzt werden (SharePoint nativ, SPFx Webpart oder Wiki-Schicht).
Häufiger Fehler: Alles exportieren und hoffen „Makros fixen wir später“. Später kommt selten – und Adoption bricht sofort.
Schritt 3: Designen Sie Ihre SharePoint-Struktur, bevor Sie irgendetwas migrieren
Wenn Sie zuerst migrieren, importieren Sie Chaos. Legen Sie vorher fest:
- Hubs und Sites
- Navigations- und Namensregeln
- Berechtigungsmodell
- Metadaten-Taxonomie
- Seiten-Templates
Schneller Praxis-Tipp: Bauen Sie einen „Knowledge Hub“ mit einer klaren Baumstruktur. Schon ein einfacher Baum lässt SharePoint für Confluence-Nutzer vertraut wirken. Die Rocketta Easy Wiki Baumstruktur ist eine natürliche Möglichkeit, das Confluence-Space-Tree-Erlebnis nachzubilden und Navigation vorhersehbar zu machen.
Häufiger Fehler: Ordner statt Metadaten, weil es „vertraut“ wirkt. Ordner skalieren nicht für Wissensmanagement – Sie bauen das gleiche Chaos wieder auf.
Schritt 4: Entwickeln Sie eine Makro-Ersatzstrategie (nicht alles braucht Custom Code)
Für jedes Makro entscheiden:
- SharePoint-native Lösung
- Wiki-Schicht-Lösung
- SPFx-Lösung
- Abschaffen (manche Makros sind später unnötig)
Schneller Praxis-Tipp: Lösen Sie zuerst Navigation + Discovery:
- Baumstruktur
- Metadaten + Tag Cloud
- beliebte Tags
Diese drei Dinge nehmen sofort den größten Frust raus. Rocketta Easy Wiki hilft dabei mit:
- Microsoft Tag Cloud
- beliebten Tags
- Contributors (Ownership sichtbar / Verantwortlichkeit)
Häufiger Fehler: Confluence 1:1 nachbauen mit Custom Development. Das wird ein Endlosprojekt. Fokus auf Nutzer-Ergebnis statt Pixel-Perfektion.
Schritt 5: Templates + Governance-Regeln bauen (damit Ihr neues System nicht wieder „verrottet“)
Hier wird SharePoint besser als Confluence – wenn Sie es richtig aufsetzen. Definieren Sie:
- Pflicht-Metadaten
- Seiten-Templates (Policy, Prozess, How-to)
- Ownership-Regeln
- Review-Zyklen
- Retention-Regeln
Schneller Praxis-Tipp: Zeigen Sie Kontributoren und Ownern sichtbar auf jeder Wissensseite. Menschen vertrauen Content schneller, wenn sie sehen, wer ihn pflegt.
Rocketta Easy Wiki zeigt Kontributoren klar – Ownership ist nicht verborgen, und Sie sehen, wer für welche Seite verantwortlich ist.
Häufiger Fehler: Kein Owner = keine Pflege. Ohne Ownership und Review-Zyklen wird Ihre neue SharePoint-Wissensbasis genauso schnell veraltet wie Confluence.
Schritt 6: Pilotieren Sie einen Space und testen Sie mit echten Nutzern (nicht nur IT)
Echte Nutzer sagen Ihnen in 2 Stunden, was kaputt ist – schneller als jedes Testszenario.
Validieren Sie:
- Navigationslogik
- Makro-Ersatz
- Suchqualität
- Lesbarkeit
- Berechtigungen
- Wie Inhalte in Teams aussehen
Schneller Praxis-Tipp: Lassen Sie Nutzer echte Aufgaben testen:
„Finde die aktuelle Reiserichtlinie.“
„Zeig mir Onboarding-Schritte.“
„Finde das richtige Projekt-Status-Template.“
Wenn sie das schnell schaffen, funktioniert Ihre Migration. Der Rocketta AI Chatbot ist hier ein großer Gewinn: Nutzer können direkt in Teams fragen, statt zu klicken.
Häufiger Fehler: Nur Admins testen. Admins kennen die Struktur – Mitarbeitende nicht. Wenn Mitarbeitende Inhalte nicht schnell finden, sagen sie „zu kompliziert“ und steigen aus.
Schritt 7: Skalieren Sie – und stoppen Sie den „Old System Fallback“
Wenn der Pilot funktioniert: Migration in Wellen. Aber eine Regel ist entscheidend: Lassen Sie Confluence nicht weiter für neue Inhalte offen.
Schneller Praxis-Tipp: Schalten Sie Confluence auf Read-only, sobald der SharePoint-Ersatz-Space live ist. Das verhindert Knowledge-Splitting und macht SharePoint zum Standard.
Häufiger Fehler: Beide Systeme „noch eine Weile“ parallel laufen lassen. Das erzeugt zwei Sources of Truth. Vertrauen bricht und Standards werden nicht mehr eingehalten.
Bonus: SharePoint wie ein Wissenssystem wirken lassen (nicht wie Storage)
Jetzt wird’s spannend – weil SharePoint aufhört, sich wie „Dateien und Ordner“ anzufühlen. Diese Dinge lassen SharePoint wie Confluence wirken (oder besser):
- Baumstruktur → vorhersehbare Navigation
- Dictionary → Definitionen & Übersetzungen direkt am Kontext
- Microsoft Tag Cloud + beliebte Tags → Themen-Exploration wie Confluence Labels
- Contributors → sichtbares Ownership und Vertrauen
- Promoted Content → wichtige Updates verschwinden nicht
- AI Chatbot → Wissen ist per Frage abrufbar, nicht durch Suchen
Diese Schicht sorgt dafür, dass Mitarbeitende sagen: „Das ist einfacher und deutlich günstiger als Confluence.”
Schlusswort: Inhalte nicht verschieben, Wissen schützen
Eine Confluence-Ersetzung funktioniert nur, wenn Menschen nicht das Gefühl haben, etwas verloren zu haben. Wenn Nutzer verlieren:
- Navigation
- Makros
- Wiederverwendbare Inhalte
- Discovery
- Vertrauen und Ownership
…werden sie SharePoint nicht annehmen, selbst wenn die Migration technisch erfolgreich war.
Wenn Sie aber migrieren mit:
- Makro-Mapping
- Struktur zuerst
- Metadaten + Discovery
- Governance + Ownership
- Einer Wiki-Schicht, die Nutzbarkeit wiederherstellt
…wird SharePoint zu einer echten Wissensplattform, nicht zu einem Storage Dump.
Die besten Migrationen sind die, bei denen Mitarbeitende am ersten Tag das neue Intranet öffnen und denken: „Gut. Alles funktioniert noch und es ist sogar einfacher.“ Genau das ist das Ziel.
