In Confluence organisiert der Seitenbaum nicht nur Inhalte. Er zeigt Mitarbeitenden, zu welchem Thema eine Seite gehört, was ihr übergeordnet ist und welche verwandte Seite als Nächstes relevant sein könnte.
Eine Arbeitsanweisung liegt beispielsweise unter einer Prozessübersicht. Eine Seite zur Fehlerbehebung gehört zu einer bestimmten Produktversion. Eine Richtlinie ergibt erst im Kontext einer Region oder Abteilung Sinn.
Confluence-zu-SharePoint-Migration: Bleibt diese Struktur erhalten?
Die kurze Antwort lautet: Ja – aber nicht als reine 1:1-Kopie. Seitenhierarchien können in eine passende SharePoint-Struktur überführt werden. Interne Links lassen sich anpassen, Labels können zu verwalteten Metadaten werden und Berechtigungen lassen sich auf Microsoft Entra ID und SharePoint abbilden.
Das beste Ergebnis ist jedoch nicht zwangsläufig eine pixelgenaue oder Ebene für Ebene identische Nachbildung des alten Seitenbaums. Ziel ist es, die gewohnte Orientierung und den fachlichen Kontext zu erhalten und die Struktur zugleich für modernes SharePoint weiterzuentwickeln.
Warum sich ein Confluence-Seitenbaum nicht eins zu eins in SharePoint abbilden lässt
Confluence ist um Bereiche und die Beziehungen zwischen über- und untergeordneten Seiten aufgebaut. Nutzer können einen Seitenbaum aufklappen und sich durch verschachtelte Inhalte bewegen – ähnlich wie durch die Kapitel eines Handbuchs. Mit Makros wie „Page Tree“ lässt sich diese Hierarchie zusätzlich innerhalb einer Seite anzeigen.
Modernes SharePoint folgt einem anderen Modell der Informationsarchitektur. Microsoft empfiehlt eine relativ flache Site-Architektur: Für eigenständige Themen, Aufgaben oder Arbeitsbereiche werden separate Sites angelegt. Hubs, Navigation und Links verbinden diese Sites, anstatt sie in tief verschachtelten Unterwebsites abzubilden. Innerhalb der Sites werden Seiten über Navigation, Metadaten und Suche organisiert und bereitgestellt. Microsoft unterscheidet dabei zwischen globaler, Hub- und lokaler Navigation. Mehr zur modernen SharePoint-Informationsarchitektur bei Microsoft.
Genau daraus entsteht eine der wichtigsten Architekturentscheidungen der Migration.
Ein Confluence-Seitenbaum repräsentiert meist mehrere Dinge gleichzeitig:
- die fachliche Beziehung zwischen Themen
- den Weg, über den Mitarbeitende Inhalte durchsuchen
- den Verantwortungsbereich eines Confluence-Bereichs
- den Berechtigungskontext einzelner Seiten oder Teilbereiche
- jahrelanges Wachstum, das die heutige Organisation möglicherweise nicht mehr abbildet
In SharePoint können diese Aufgaben von unterschiedlichen Komponenten übernommen werden. Ein Zweig wird möglicherweise zu einer eigenen Site. Ein anderer wird als Navigationskategorie abgebildet. Beziehungen zwischen Seiten können über einen Wiki-Seitenbaum oder Metadaten sichtbar werden. Inhalte mit abweichenden Zugriffsanforderungen benötigen unter Umständen eine eigene Sicherheitsgrenze.
Den Seitenbaum zu bewahren, heißt deshalb, seine nützliche Logik zu erhalten – nicht jede alte Ebene in ein neues Menü zu zwingen.
So wird die Struktur übersetzt
flowchart TD
A[„Confluence-Bereich und Seitenbaum“] –> B[„Strukturelles Mapping“]
B –> C[„SharePoint-Sites und -Seiten“]
B –> D[„Navigation oder Easy-Wiki-Seitenbaum“]
B –> E[„Metadaten, Links und Berechtigungen“]
Abbildung: Eine Confluence-Hierarchie wird in aufeinander abgestimmte SharePoint-Strukturen überführt, nicht in ein einziges Ziel kopiert.
Beim Mapping wird aus der Migration ein Projekt für Informationsarchitektur – und nicht nur ein Datentransfer. Dabei sind 4 Fragen getrennt zu beantworten:
- Wo sollen die Inhalte künftig liegen?
- Wie werden Mitarbeitende durch die Inhalte navigieren?
- Wie bildet SharePoint die Beziehungen zwischen den Seiten ab?
- Wer darf die Inhalte sehen und pflegen?
Confluence-Seitenbaum: Elemente und mögliche Ziele in SharePoint
Ein universelles 1:1-Mapping gibt es nicht. Die folgende Tabelle zeigt, welche Entscheidungen wir vor der Migration eines repräsentativen Confluence-Bereichs treffen. Die Logik ist bewusst entscheidungsorientiert: Eine Seite kann technisch migrierbar sein und trotzdem nicht in das künftige Live-System gehören.
| Confluence-Element | Entscheidung vor der Migration | Mögliches SharePoint-Ziel | Was validiert werden muss |
| Bereich | Handelt es sich um einen gemeinsamen Verantwortungs- und Sicherheitsbereich oder um mehrere? | SharePoint-Site, mehrere Sites unter einem Hub oder ein definierter Wiki-Bereich | Verantwortlichkeit, Zielgruppe, Berechtigungen und künftige Pflege |
| Oberste Seite | Ist sie eigenständiger Inhalt oder lediglich ein Container für untergeordnete Seiten? | Übersichtsseite, Navigationskategorie oder Inhaltsseite | Müssen Mitarbeitende die Seite lesen oder nur über sie navigieren? |
| Untergeordnete Seite | Muss die Beziehung zur übergeordneten Seite sichtbar bleiben? | Moderne SharePoint-Seite plus Navigation, Metadaten oder Position im Wiki-Seitenbaum | Kontext, Brotkrümelnavigation, verwandte Seiten und mobile Nutzbarkeit |
| Tief verschachtelter Zweig | Unterstützt die Tiefe die Orientierung oder ist sie nur historisch gewachsen? | Flachere Navigation, Themenseiten, Filter oder separate Site | Anzahl der Klicks, verständliche Benennung und Auffindbarkeit über die Suche |
| „Page Tree“- oder „Children Display“-Makro | Ist die aufklappbare Baumnavigation für die Nutzung wesentlich? | Lokale Navigation oder Seitenbaum in Easy Wiki | Vertrautes Browsen, Sortierung und Sichtbarkeit untergeordneter Themen |
| Labels | Welche Labels sind noch aussagekräftig, welche doppelt, unklar oder veraltet? | Verwaltete SharePoint-Metadaten und Term Store | Kontrollierte Werte, Filter, Suche und Verantwortlichkeit für die Taxonomie |
| Interne Seitenlinks | Gibt es für jede verlinkte Quellseite ein bestätigtes Ziel? | Umgeschriebene Links zu den entsprechenden SharePoint-Seiten | Defekte Links, Weiterleitungen und Verweise auf archivierte Inhalte |
| Bereichs- und Seitenberechtigungen | Sind Einschränkungen beabsichtigt, geerbt oder längst überholt? | Microsoft-Entra-ID-Gruppen und SharePoint-Berechtigungen | Zugriff mit repräsentativen Nutzerkonten – nicht nur mit Administratorkonten |
| Anhänge und eingebettete Medien | Bleibt das Element an die Seite gebunden oder gehört es in eine verwaltete Bibliothek? | Dokumentbibliothek, Seiten-Webpart oder andere Zielkomponente | Version, Metadaten, Zugriff und Verknüpfung mit der Seite |
| Archivierte oder doppelte Zweige | Wird der Inhalt in der aktiven Wissensbasis noch benötigt? | Archiv, PDF-Export, zusammengeführte Seite oder Ausschluss | Aufbewahrungsanforderungen und Vorhandensein einer freigegebenen aktuellen Version |
4 Wege, wie sich ein Seitenbaum bei der Migration verändern kann
1. Die vertraute Baumstruktur erhalten
Bei Prozess-, Technik- oder Richtliniendokumentationen kann die Hierarchie selbst einen hohen Nutzwert haben. Mitarbeitende erschließen sich das Thema über Kapitel und Unterthemen. Würde der Seitenbaum entfernt, wäre die neue Umgebung möglicherweise schwerer zu nutzen als die alte.
In diesem Fall können die Seitenbeziehungen migriert und als hierarchische Navigation neu aufgebaut werden. Rockettas Easy Wiki für SharePoint ergänzt SharePoint um eine Baumstruktur für Teams, die Wissen weiterhin ähnlich wie in Confluence durchsuchen möchten.
Dieser Ansatz ist häufig sinnvoll, wenn:
- die Hierarchie stabil und den Nutzern vertraut ist
- die Seiten gemeinsam als ein Wissensgebiet gepflegt werden
- Mitarbeitende nach Themen browsen und sich nicht ausschließlich auf die Suche verlassen
- der Seitenbaum nicht so tief ist, dass Nutzer die Orientierung verlieren
2. Einen Confluence-Bereich auf mehrere SharePoint-Sites verteilen
Ein Confluence-Bereich kann Inhalte verschiedener Abteilungen, Regionen oder Produktteams enthalten. Häufig liegen dort außerdem allgemein zugängliches Wissen und vertrauliche Inhalte nebeneinander.
Wird der gesamte Bereich in einer einzigen SharePoint-Site nachgebaut, bleibt die sichtbare Struktur zwar vertraut. Gleichzeitig übernimmt das Unternehmen möglicherweise ein ungeeignetes Governance-Modell in Microsoft 365.
Das bessere Ziel können mehrere SharePoint-Sites sein, die über einen Hub oder eine gemeinsame Navigation verbunden werden. Der Weg für die Nutzer bleibt zusammenhängend, während Verantwortlichkeiten und Zugriffe sinnvoller verteilt sind.
Dieser Ansatz ist häufig sinnvoll, wenn:
- einzelne Zweige unterschiedliche fachliche Eigentümer haben
- sich die Berechtigungsgrenzen deutlich unterscheiden
- die Inhalte verschiedene Zielgruppen ansprechen
- jeder Bereich einen eigenen Lebenszyklus und Veröffentlichungsprozess benötigt
3. Einen zu tief gewachsenen Seitenbaum abflachen
Nicht jede übernommene Ebene sollte erhalten bleiben. Ein Pfad mit sieben Ebenen zeigt möglicherweise nur, wie Seiten über Jahre ergänzt wurden – nicht, wie Mitarbeitende heute nach Informationen suchen.
Wer alle sieben Ebenen kopiert, schafft eine Umgebung, die dem Migrationsteam vertraut erscheint, aber alle anderen weiterhin unnötig viele Klicks kostet.
Einige Zweige lassen sich besser abbilden durch:
- einen kürzeren Navigationspfad
- eine thematische Übersichtsseite
- Filter auf Basis von Metadaten
- Links zu verwandten Inhalten
- eine suchbasierte Erschließung
Dabei geht keine Struktur verloren. Sie wird lediglich in eine Form übersetzt, die sich in SharePoint besser pflegen und weiterentwickeln lässt.
4. Zweige entfernen, die nicht zu aktiven Inhalten werden sollten
Migrationsinventare enthalten häufig leere Container, abgeschlossene Projektbereiche, doppelte Prozessbeschreibungen und Seiten ohne erkennbare Verantwortung. Allein ihre Position im Seitenbaum lässt sie weiterhin offiziell erscheinen – auch wenn niemand bestätigen kann, ob die Inhalte noch gelten.
Vor der Migration benötigt deshalb jeder Zweig eine klare Entscheidung:
- migrieren
- zusammenführen
- überarbeiten
- archivieren
- ausschließen
So verhindert das Projekt, dass eine veraltete Informationsarchitektur nur deshalb reproduziert wird, weil sie bereits vorhanden ist.
Mit der Hierarchie müssen auch die Links erhalten bleiben
Ein Seitenbaum besteht nicht nur aus der linken Navigation. Confluence-Seiten verweisen häufig auf übergeordnete Seiten, benachbarte Inhalte und Seiten in anderen Bereichen.
Wird die sichtbare Hierarchie neu aufgebaut, während interne Links weiterhin auf Confluence zeigen, landen Nutzer nach dem Umstieg entweder wieder im Altsystem oder auf einer nicht mehr erreichbaren Seite.
Bei einer Confluence-zu-SharePoint-Migration mit Rocketta werden Links auf Confluence-Seiten erkannt, den neuen SharePoint-Zielen zugeordnet und in den migrierten Seiten angepasst. Wo erforderlich, können zusätzlich automatische Weiterleitungen von alten Confluence-URLs eingerichtet werden.
Die Linkprüfung sollte sich nicht auf das sichtbare Navigationsmenü beschränken. Zu testen sind insbesondere:
- Links im Fließtext
- Links in Makros oder wiederverwendeten Inhaltsabschnitten
- Verweise zwischen verschiedenen Confluence-Bereichen
- Links aus externer Dokumentation oder gespeicherten Lesezeichen
- Links auf Inhalte, die zusammengeführt oder archiviert werden
Ohne diese Prüfung kann der Seitenbaum intakt aussehen, obwohl das dahinterliegende Wissensnetz bereits unterbrochen ist.
Berechtigungen können die Form des Seitenbaums verändern
Confluence-Bereiche und einzelne Seiten können unterschiedliche Zugriffsbeschränkungen besitzen. Manche davon bilden echte Anforderungen an Vertraulichkeit oder Compliance ab. Andere sind historische Ausnahmen, die seit Jahren niemand geprüft hat.
Rocketta berücksichtigt bei der Migrationsplanung die Zuordnung von Nutzern und Berechtigungen zu Microsoft Entra ID und SharePoint-Gruppen. Berechtigungs-Mapping sollte jedoch nicht als rein mechanischer Namensabgleich behandelt werden.
Für jeden eingeschränkten Zweig ist zu klären:
- Wer benötigt im Zielsystem tatsächlich Zugriff?
- Gilt die Einschränkung für eine Seite, ein gesamtes Thema oder eine vollständige Site?
- Welche Gruppe verantwortet diesen Zugriff nach dem Go-live?
- Sehen Nutzer Navigationslinks zu Inhalten, die sie nicht öffnen dürfen?
Das ist entscheidend, weil die ideale Inhaltshierarchie nicht immer der idealen Sicherheitsstruktur entspricht. Hat ein Zweig eine deutlich andere Zielgruppe, kann eine eigene SharePoint-Site sinnvoller sein als zahlreiche Ausnahmen auf Seitenebene.
Warum die Testmigration einen schwierigen Seitenbaum enthalten sollte
Ein Proof of Concept mit dem saubersten und einfachsten Confluence-Bereich beweist wenig. Der repräsentative Testbereich sollte genau die Elemente enthalten, die das Zielbild beeinflussen können:
- mehrere Hierarchieebenen
- bereichsübergreifende Links
- Anhänge und eingebettete Medien
- Labels für Navigation oder Filter
- eingeschränkte Seiten
- häufig verwendete Standard- und Drittanbieter-Makros
- Inhalte, die seit dem Export verändert wurden
Im Rocketta-Migrationsprozess werden bei einer Testmigration unter anderem Seitenlayout, Makros, Anhänge, Links, Navigation, Metadaten und Berechtigungen vor der Produktivmigration geprüft. Die Ergebnisse fließen anschließend in den Migrationsplan ein.
Größere Umgebungen lassen sich in Wellen migrieren und vor dem finalen Umstieg validieren. Bis zur Abnahme bleibt die bestehende Confluence-Umgebung als Referenz verfügbar.
Ein sinnvoller Test prüft nicht nur, ob das System einen erfolgreichen Lauf protokolliert. Er beantwortet konkrete Fragen aus dem Arbeitsalltag:
- Findet ein Mitarbeiter dieselbe Arbeitsanweisung, ohne ihren neuen Ablageort zu kennen?
- Erkennt die für eine Seite verantwortliche Person, wo die Seite hingehört und wie sie aktualisiert wird?
- Sieht ein Nutzer mit eingeschränkten Rechten den richtigen Zweig – und nichts darüber hinaus?
- Führen Links zum vorgesehenen SharePoint-Ziel?
- Kann das Team aktive migrierte Inhalte eindeutig von archiviertem Material unterscheiden?
Scheitern diese Aufgaben, ist die Hierarchie noch nicht in einem praktisch nutzbaren Sinn erhalten.
Was Migrationsverantwortliche vor der Freigabe des Zielbilds entscheiden sollten
Vor der vollständigen Migration sollten IT, Wissensmanagement und Fachbereiche folgende Punkte gemeinsam klären:
Welche Teile des bestehenden Seitenbaums sind weiterhin nützlich?
Alter und Seitenzahl sind kein verlässliches Maß für den Wert eines Inhalts. Entscheidend sind Aktualität, Nutzung, Verantwortung und fachliche Relevanz.
Welche Confluence-Bereiche werden zu einer Site – und welche werden aufgeteilt?
Die Entscheidung sollte sich nach Verantwortung, Zielgruppe und Sicherheitsanforderungen richten, nicht nur nach der bisherigen Bereichsgrenze.
Wo ist eine sichtbare Baumnavigation unverzichtbar?
Sie sollte dort eingesetzt werden, wo Mitarbeitende zusammenhängendes Wissen tatsächlich über die Hierarchie erschließen – nicht automatisch in jedem Bereich.
Welche Beziehungen sollten als Metadaten abgebildet werden?
Themen, Dokumenttypen, Regionen und Abteilungen können als kontrollierte Felder wertvoller sein als zusätzliche Navigationsebenen.
Wer verantwortet jeden Hauptbereich nach dem Go-live?
Ein erhaltener Seitenbaum ohne klare Pflegeverantwortung veraltet erneut – unabhängig davon, wie gut die technische Migration war.
Wie werden alte Links und Lesezeichen behandelt?
Vorab ist zu entscheiden, ob angepasste Links, Weiterleitungen oder beides erforderlich sind.
Welche Inhalte werden nicht migriert?
Entscheidungen zu Archivierung und Ausschluss müssen freigegeben, dokumentiert und in der Testmigration überprüfbar sein.
Diese Festlegungen vereinfachen die Abnahme, weil jede größere strukturelle Änderung einen nachvollziehbaren Grund hat.
Der Seitenbaum sollte als Nutzungserlebnis überleben – nicht als Fossil
Mitarbeitenden ist gleichgültig, ob die Beziehung zwischen über- und untergeordneten Seiten technisch in einer Migrationsdatenbank erhalten wurde. Für sie zählt, ob sie verstehen, wo sie sich befinden, die nächste relevante Seite finden und darauf vertrauen können, die richtigen Informationen erreicht zu haben.
Dafür kann ein vertrauter Seitenbaum nötig sein. In anderen Fällen sind eine flachere Navigation, bessere Metadaten oder mehrere miteinander verbundene SharePoint-Sites die passendere Lösung. In vielen Unternehmen ist es eine Kombination daraus.
Rockettas Migrationsansatz erhält relevante Seitenhierarchien, passt Seitenstrukturen an modernes SharePoint an, schreibt interne Links um, ordnet Berechtigungen zu und überführt sinnvolle Labels in verwaltete Metadaten. Wo eine Wiki-ähnliche Navigation wichtig bleibt, kann Easy Wiki den passenden Seitenbaum in SharePoint bereitstellen.
Das beste Ergebnis ist keine SharePoint-Kopie des gestrigen Confluence. Es ist eine Wissensstruktur, die Mitarbeitende am ersten Tag wiedererkennen und die das Unternehmen auch Jahre später noch verlässlich steuern kann.
Wenn Sie die Zukunft Ihrer Confluence-Umgebung bewerten – insbesondere mit Blick auf das angekündigte Ende von Atlassian Data Center – sollten Sie den Seitenbaum analysieren, bevor Sie die Zielarchitektur festlegen. Er sagt häufig mehr über den tatsächlichen Migrationsaufwand aus als die reine Seitenzahl.
