Term Store am Limit: Taxonomie-Migration in den geteilten SharePoint-Online-Tenant

On-Premises war der Term Store praktisch grenzenlos — also wurde er auch so benutzt. In unserem Migrationsprojekt (Serie ab Teil 1) hatte jedes Großprojekt eigene Termsets: räumliche Verortung der Anlagen, Baustoffkataloge, Anlagenstrukturen, Projektorganisation. Multipliziert über 130+ Projekte ergibt das Millionen von Terms.

SharePoint Online setzt dem harte Grenzen: 1 Million Terms pro Term Store — tenantweit. Und dieser Tenant gehört nicht einem Projekt, nicht einmal einer Abteilung, sondern dem gesamten Konzern. Die alte Architektur „jedes Projekt bringt seine Taxonomie mit” ist in der Cloud nicht verhandelbar gescheitert, bevor die Migration überhaupt begann.

Das Problem ist größer als das Limit

Selbst wenn das Limit höher wäre, bleiben strukturelle Gründe gegen die 1:1-Übernahme:

• Geteilter Tenant = geteilte Governance. Ein Term Store, den zehn Konzernbereiche gemeinsam nutzen, verträgt keine Projekt-Wildwuchs-Termsets. Jeder Term ist tenantweite Infrastruktur.
• Lookup-Listen sind kein Ausweichventil. Der historische Zwilling der Taxonomie — riesige Lookup-Listen — läuft in SharePoint Online gegen eigene Grenzen: den List View Threshold und das Limit der Lookup-Spalten pro Abfrage. Wer Taxonomie einfach in Lookups kippt, tauscht ein Limit gegen zwei.
• Abfragbarkeit. Terms, die nur ein einziges Projekt je verwendet hat, bieten keinen konzernweiten Mehrwert — sie sind projektlokale Daten und sollten auch so gespeichert werden.

Unsere Ziel-Architektur

Wir haben die Felder nach tatsächlichem Nutzungsmuster klassifiziert:

Nutzungsmuster in der Quelle	Zieltyp in SharePoint Online
Konzernweit einheitliches Vokabular (z. B. Dokumentklassen)	Managed Metadata — ein globales, konsolidiertes Termset
Projektlokale Strukturwerte (räumliche Verortung, Anlagen)	Text-/Note-Felder mit normalisierten Werten
Kleine, stabile Wertemengen	Choice-Felder
Projektlokale Referenzdaten mit Beziehungscharakter	Lookup auf schlanke, projektlokale Listen

Der Grundsatz: Nur was konzernweit gepflegt wird, darf in den Term Store. Alles andere wird beim Migrieren transformiert.

Die technische Seite: Feldtyp-Wechsel beim Import

Ein Taxonomiefeld in ein Textfeld zu überführen klingt trivial — ist es nicht. SharePoint speichert Taxonomiewerte in einem Wire-Format, das beim naiven Kopieren als Datenmüll am Ziel landet:

-1;#Bahnhof Mitte|a1b2c3d4-e5f6-7890-abcd-ef1234567890

Wer das ungefiltert in ein Textfeld schreibt, hat GUID-Suffixe und ;#-Präfixe in der Benutzeroberfläche. Unsere Transformations-Engine normalisiert deshalb jeden Wert typabhängig:

// Taxonomie-Wire-Format → sauberer Textwert
// "-1;#Bahnhof Mitte|a1b2..." → "Bahnhof Mitte"
// Mehrwertig: alle Label extrahieren, GUIDs verwerfen
static string TaxonomyToText(string wireValue) =>
    string.Join("; ",
        WireEntries(wireValue)              // an ";#"-Paaren splitten
            .Select(e => e.LabelBeforePipe()) // "|<guid>"-Suffix abschneiden
            .Where(l => !string.IsNullOrWhiteSpace(l)));

Zwei Fallen, die wir erst im Live-Betrieb gefunden haben:

1. Passthrough-Löcher: Note- und Choice-Felder, die historisch Taxonomie-Rohwerte enthielten, wurden anfangs ungefiltert durchgereicht — der GUID-Müll fiel erst im Ziel auf. Die Normalisierung muss für alle Zieltypen greifen, nicht nur für die offensichtlichen.
2. Der Parity-Check muss dieselbe Normalisierung sprechen: Wer Quelle und Ziel vergleicht, ohne ID;#-Präfixe und |guid-Suffixe zu kanonisieren, produziert hunderte False-Positive-Differenzen und verliert das Vertrauen ins eigene Abnahme-Werkzeug. Transformations- und Vergleichslogik gehören in denselben, geteilten Code.

Konsolidierung mit Fallback: das Unterlagenarten-Mapping

Das konzernweite Termset für Dokumentklassen („Unterlagenarten”) musste aus dutzenden historischen Varianten konsolidiert werden — Name-Drift über zehn Jahre, projektspezifische Sonderformen, umbenannte Terms. Unser Mapping arbeitet als Regelkette:

Quellwert
  │ 1. exakter Match im Ziel-Termset?          → Ziel-Term (per GUID)
  │ 2. Treffer in Synonym-/Historien-Tabelle?  → gemappter Ziel-Term + Log
  │ 3. Treffer nach Normalisierung?            → gemappter Ziel-Term + Log
  └ 4. kein Treffer                            → Fallback-Term + Nacharbeits-Register

Der entscheidende Punkt ist nicht die Kette selbst, sondern ihre Auditierbarkeit: Jeder Fallback landet in einem Register, das die Fachabteilung nach der Migration projektweise abarbeiten kann. „Unresolved” ist bei uns ein Zustand mit Besitzer und Liste — kein stilles Datenloch.

Für Werte, die per Taxonomie migriert werden, gilt zusätzlich: Das Manifest der Migration API braucht echte Term-GUIDs des Ziel-Termsets — Label-basiertes Mapping reicht nicht, sonst legt der Import-Worker orphaned Labels an (mehr zur Migration API in Teil 3).

Was wir heute anders empfehlen

1. Term-Nutzung messen, bevor migriert wird. Ein Termset mit 200.000 Terms, von denen 1.900 je verwendet wurden, ist kein Migrations-, sondern ein Löschkandidat.
2. Feldtyp-Entscheidung pro Feld, nicht pro Feldtyp. „Alle Taxonomie wird Text” ist genauso falsch wie „alles bleibt Taxonomie”.
3. Wire-Formate ernst nehmen. Die ;#/|guid-Artefakte sind die häufigste Quelle für „kaputte Metadaten” nach Feldtyp-Transformationen.
4. Mapping-Protokoll als Abnahme-Artefakt einplanen. Die Frage der Fachabteilung ist nie „habt ihr gemappt?”, sondern „was genau habt ihr wohin gemappt — und wo müssen wir ran?”

---

Ihr Term Store platzt, Ihre Lookup-Listen auch, und der Konzern-Tenant hat eigene Regeln? Genau diese Transformation haben wir im 25-TB-Maßstab gebaut. Wir unterstützen Sie gerne — von der Taxonomie-Analyse bis zum auditierbaren Mapping.

Alle Teile der Serie:

1. Warum keine 1:1-Migration
2. 25 TB SharePoint-Migration: Warum Standard-Tools nicht reichen
3. Die SharePoint Migration API in der Praxis
4. Term Store am Limit: Taxonomie-Migration im geteilten Tenant (dieser Beitrag)
5. Versionshistorie intelligent migrieren
6. Provisioning im Großformat: PnP, Throttling, Berechtigungen