Ich habe über die letzten drei Jahre etwa 40 Projekte zu Sanity migriert. Einige waren saubere zweiwöchige Sprints. Andere entwickelten sich zu dreimonatigen Marathons, die mich an meinen Karrierechoices zweifeln ließen. Der Unterschied hängt fast nie vom Source CMS ab — er hängt von der Vorbereitung, den Content-Modeling-Entscheidungen und davon ab, ehrlich zu sein, worauf man sich einlässt.

Dies ist der Leitfaden, den ich mir hätte wünschen, als ich mit CMS-Migrationen anfing. Er behandelt den Umzug von WordPress, Contentful und Drupal in die Sanity GROQ-gestützte Welt. Ich werde ehrlich sein, wo Sanity glänzt, wo es frustriert, und wie realistische Zeitpläne aussehen.

Inhaltsverzeichnis

Sanity Migration Playbook: Migration von WordPress, Contentful oder Drupal

Warum Teams 2025 zu Sanity wechseln

Lassen Sie mich mit den offensichtlichen Dingen anfangen. Sanity's Echtzeit-Collaborative-Editing, anpassbare Studio und strukturierter Content-Ansatz sind wirklich gut. Aber der Grund, warum die meisten Teams uns über eine Migration kontaktieren, ist nicht, weil sie einen Blog-Post über Sanity's Features gelesen haben. Es ist, weil etwas kaputt gegangen ist.

WordPress-Seiten stoßen bei etwa 50.000+ Content-Teilen mit komplexen Custom Post Types an Skalierungsgrenzen. Contentful's Preismodell beginnt bei der Enterprise-Tier zu drücken — wir haben Teams gesehen, die mit $3.500+/Monat Rechnungen für das, was letztlich eine Content API ist, konfrontiert werden. Drupal-Teams können keine Entwickler mehr finden, zumindest nicht solche, die 2025 mit PHP-Templating arbeiten wollen.

Sanity's Preismodell ist für die meisten Teams genuinely vorhersehbarer. Der kostenlose Tier deckt bis zu 100K API-Anfragen/Monat und 500K Assets ab. Der Growth-Plan zu $99/Monat/Projekt gibt Ihnen 2.5M API-Anfragen und 1M Assets. Zum Vergleich: Contentful's Team-Plan kostet $300/Monat und Contentful's Premium-Tier kann leicht über $2.000/Monat hinausgehen.

Aber hier ist meine ehrliche Meinung: Wenn Ihr derzeitiges CMS funktioniert und Ihr Team produktiv ist, migrieren Sie nicht nur, weil Sanity neuer oder cooler ist. Migrationen kosten immer mehr als gedacht.

Pre-Migration Audit: Der Schritt, den alle überspringen

Bevor Sie eine einzige Zeile Migration-Code schreiben, brauchen Sie einen Content-Audit. Nicht nur einen schnellen Scan — einen echten Audit. So sieht das aus:

Content Inventar

Dokumentieren Sie jeden Content-Type, jedes Feld, jede Beziehung. Ich verwende eine Tabellenkalkulation mit diesen Spalten:

  • Content-Type-Name
  • Gesamtzahl Elemente
  • Felder (mit Typen)
  • Beziehungen zu anderen Content-Types
  • Media-Anhänge (Anzahl und Gesamtgröße)
  • Benutzerdefinierte Funktionalität (Shortcodes, Widgets, Embeds)
  • Zuletzt geändert
  • Noch relevant? (Ja/Nein/Vielleicht)

Sie werden schockiert sein, wie viel Content Altlast ist. Bei einer WordPress-Migration hatte ein Kunde 12.000 Beiträge. Nach dem Audit waren nur noch 4.200 relevant. Das sind 65% weniger Content zum Migrieren, Testen und Validieren.

Technical Dependency Mapping

Erstellen Sie eine Liste mit jedem Plugin, Modul oder Integration, die Ihr derzeitiges CMS verwendet. Bestimmen Sie für jede:

  1. Kann Sanity das nativ handhaben?
  2. Gibt es ein Sanity-Plugin dafür?
  3. Müssen wir eine benutzerdefinierte Lösung bauen?
  4. Können wir das ganz fallen lassen?

Dieses Mapping allein spart Ihnen Wochen an Überraschungen später.

Team Readiness Assessment

Sanity Studio basiert auf React. Ihre Content-Editoren benötigen Training. Ihre Entwickler müssen GROQ lernen (oder GraphQL verwenden, obwohl GROQ dort ist, wo Sanity wirklich glänzt). Budgetieren Sie 1-2 Wochen für Team-Onboarding — nicht als nice-to-have, sondern als Posten.

WordPress zu Sanity Migration

WordPress ist die häufigste Source CMS, von der wir migrieren. Es ist auch die kniffligste, weil WordPress nicht nur ein CMS ist — es ist eine ganze Anwendungsplattform, bei der Leute alles mögliche angebaut haben.

Was sauber überträgt

  • Beiträge und Seiten (grundlegender Content)
  • Kategorien und Tags
  • Vorgestellte Bilder
  • Autordaten
  • Grundlegende Custom Fields (ACF, Meta Box)

Was unordentlich wird

  • Gutenberg-Blöcke: Jeder Block-Typ benötigt einen entsprechenden Sanity Portable Text Custom Block oder Object-Typ. Wenn Sie 15+ Custom Gutenberg Blöcke haben, budgetieren Sie erhebliche Zeit hier.
  • Shortcodes: Diese müssen analysiert, interpretiert und in Portable Text Annotationen oder Custom Blöcke konvertiert werden. WPBakery und Elementor Shortcodes sind besonders schmerzhaft.
  • Plugin-generierter Content: WooCommerce-Produkte, Yoast SEO-Daten, ACF Repeater Fields — jedes erfordert benutzerdefinierte Migration Logic.
  • Medienbibliothek: WordPress speichert mehrere Bildgrößen. Sanity behandelt Bildtransformationen spontan, sodass Sie nur die Originale benötigen. Aber die Originale in einem unordentlichen wp-uploads Ordner zu finden? Das wird fun.

Migration Script Ansatz

Ich verwende typischerweise ein Node.js-Script, das die WordPress REST API anspricht und in Sanity's Mutation API schreibt:

import { createClient } from '@sanity/client'
import fetch from 'node-fetch'

const sanity = createClient({
  projectId: 'your-project-id',
  dataset: 'production',
  token: process.env.SANITY_WRITE_TOKEN,
  apiVersion: '2025-01-01',
  useCdn: false,
})

const WP_API = 'https://yoursite.com/wp-json/wp/v2'

async function migratePosts(page = 1) {
  const res = await fetch(`${WP_API}/posts?per_page=100&page=${page}`)
  const posts = await res.json()
  const totalPages = res.headers.get('x-wp-totalpages')

  const transaction = sanity.transaction()

  for (const post of posts) {
    transaction.createOrReplace({
      _id: `wp-post-${post.id}`,
      _type: 'post',
      title: post.title.rendered,
      slug: { current: post.slug },
      publishedAt: post.date,
      // Body erfordert HTML-zu-Portable-Text-Konvertierung
      body: await convertToPortableText(post.content.rendered),
    })
  }

  await transaction.commit()
  console.log(`Migrated page ${page} of ${totalPages}`)

  if (page < totalPages) {
    await migratePosts(page + 1)
  }
}

Die convertToPortableText Funktion ist, wo 80% der Komplexität lebt. Ich verwende das @sanity/block-tools Paket kombiniert mit jsdom für HTML-Parsing. Es behandelt grundlegende HTML gut, aber Custom-Elemente und Shortcodes benötigen individuelle Handler.

Realistischer Zeitplan

Für eine typische WordPress-Seite mit 500-2.000 Beiträgen, Standard-Custom-Feldern und einer Handvoll Custom Post Types: 4-8 Wochen einschließlich Content Modeling, Migration Scripting, Validierung und Editor Training.

Sanity Migration Playbook: Migration von WordPress, Contentful oder Drupal - Architektur

Contentful zu Sanity Migration

Contentful-zu-Sanity ist tatsächlich der reibungsloseste Migrationspfad der drei. Warum? Weil beide strukturierte Content-Plattformen mit ähnlichen mentalen Modellen sind. Ihr Content ist bereits in einem Headless CMS mit definierten Content-Types und Feldern.

Wichtige Unterschiede zu beachten

Feature Contentful Sanity
Rich Text Rich Text (JSON-basiert) Portable Text (JSON-basiert)
Content Modeling Web UI Code-definierte Schemas
Query Language GraphQL / REST GROQ (+ GraphQL)
Lokalisierung Eingebaute Field-Level Plugin oder benutzerdefiniert
Referenzen Links (Entry/Asset) Referenzen mit Typen
Webhooks Ja Ja
Asset-Handling Eingebautes CDN Sanity CDN + Hotspot/Crop
Preisgestaltung (Mid-Tier) ~$300/mo (Team) $99/mo (Growth)

Rich Text Konvertierung

Contentful's Rich Text und Sanity's Portable Text sind beide JSON-basiert, was großartig ist. Aber sie haben unterschiedliche Strukturen. Sie müssen einen Transformer schreiben:

function contentfulRichTextToPortableText(richTextField) {
  return richTextField.content.map(node => {
    switch (node.nodeType) {
      case 'paragraph':
        return {
          _type: 'block',
          style: 'normal',
          children: node.content.map(mapInlineContent),
        }
      case 'heading-2':
        return {
          _type: 'block',
          style: 'h2',
          children: node.content.map(mapInlineContent),
        }
      case 'embedded-entry-block':
        // Zu Ihrem Custom Portable Text Typ mappen
        return mapEmbeddedEntry(node)
      // ... alle Node-Typen handhaben
    }
  }).filter(Boolean)
}

Content Type zu Schema Mapping

Contentful Content Types mappen sich ziemlich direkt zu Sanity Document und Object Types. Der größte Wechsel ist, dass Sanity Schemas im Code definiert sind (JavaScript/TypeScript), nicht in einer Web UI. Dies ist eigentlich ein riesiger Vorteil — Ihr Content Model lebt in der Versionskontrolle.

Verwenden Sie die Contentful Management API, um Ihr Content Model zu exportieren, dann schreiben Sie ein Script, das Sanity Schema-Dateien generiert:

contentful space export --space-id YOUR_SPACE_ID --export-dir ./export

Realistischer Zeitplan

Für einen Contentful Space mit 10-20 Content Types und 5.000-10.000 Einträgen: 3-5 Wochen. Es ist schneller, weil Sie bereits in strukturiertem Content denken.

Drupal zu Sanity Migration

Drupal-Migrationen sind diejenigen, die mich eine zweite Tasse Kaffee einschenken lassen. Nicht, weil Drupal schlecht ist — es ist ein mächtiges System. Aber Drupal-Seiten sind dazu neigt, alt zu sein, hochgradig angepasst zu sein, und auf einer Infrastruktur zu laufen, die niemand wirklich vollständig versteht.

Die Drupal-spezifischen Herausforderungen

  • Content Types mit 50+ Feldern: Drupal macht es einfach, Felder hinzuzufügen. Zu einfach. Ich habe Content Types mit 80 Feldern gesehen, die Hälfte davon ungenutzt.
  • Taxonomy Term Referenzen: Drupal's Taxonomy-System ist flexibel, kann aber tiefe verschachtelte Hierarchien erstellen, die für Sanity vereinfacht werden müssen.
  • Paragraphs Modul: Wenn die Seite das Drupal Paragraphs Modul verwendet (und die meisten modernen Drupal-Seiten tun das), wird jeder Paragraph Type zu einem Portable Text Block Type oder Sanity Object. Dies ist die größte einzelne Aufgabe.
  • Media-Entitäten: Drupal 9/10's Media-System ist komplexer als WordPress's. Mehrere Medientypen, wiederverwendbare Media-Entitäten und Dateifeldkonfigurationen müssen alle gemappt werden.
  • Mehrsprachiger Content: Drupal's Übersetzungssystem ist sophisticated. Sanity hat keine eingebaute Lokalisierung auf dem gleichen Level — Sie benötigen das @sanity/document-internationalization Plugin oder einen Field-Level-Ansatz.

Migration Ansatz

Ich bevorzuge die Verwendung von Drupal's JSON:API Modul (seit Drupal 9.x enthalten im Core) als Extraktionslayer:

async function fetchDrupalContent(type, page = 0) {
  const limit = 50
  const offset = page * limit
  const url = `${DRUPAL_URL}/jsonapi/node/${type}?page[limit]=${limit}&page[offset]=${offset}&include=field_image,field_paragraphs`

  const res = await fetch(url, {
    headers: { Authorization: `Basic ${DRUPAL_AUTH}` },
  })
  return res.json()
}

Für ältere Drupal 7 Seiten ohne JSON:API müssen Sie möglicherweise die Datenbank direkt abfragen. Drupal 7's Datenbankschema ist ... ein Erlebnis. Die field_data_* Tabellen werden Ihre Träume heimsuchen.

Realistischer Zeitplan

Drupal-Migrationen variieren stark. Eine unkomplizierte Drupal 10 Seite mit 5-10 Content Types: 5-8 Wochen. Eine Legacy Drupal 7 Seite mit 30+ Content Types, Paragraphs und mehrsprachigem Content: 8-16 Wochen. Ich übertreibe nicht.

Content Modeling: Schemas richtig hinbekommen

Hier ist die Sache, die die meisten Migrations-Guides nicht erzählen: Replizieren Sie nicht Ihr altes Content Model in Sanity. Dies ist Ihre Gelegenheit, Jahre von angesammelter Content-Schulden zu beheben.

Häufige Modeling-Fehler

  1. Erstellen einer 1:1 Field-Zuordnung: Nur weil WordPress ein "Untertitel" Custom Field hatte, heißt das nicht, dass Sanity eines braucht. Vielleicht sollte es Teil eines strukturierten "Hero" Objekts sein.
  2. Zu tiefes Verschachteln von Objekten: Sanity lässt Sie Objekte tief verschachteln. Widerstehen Sie dem Drang. Flache(re) Schemas sind einfacher mit GROQ zu abfragen und einfacher für Editoren, damit zu arbeiten.
  3. Portable Text's Kraft ignorieren: Werfen Sie nicht einfach HTML in ein einzelnes Textfeld. Entwerfen Sie Custom Block Types, die Ihren Content-Mustern entsprechen. Ein "Callout" Block, ein "Code Snippet" Block, ein "Image mit Caption" Block — diese machen Editoren das Leben besser.

Schema Design Prozess

Ich folge dieser Reihenfolge:

  1. Audit vorhandenes Content (durchgeführt in Pre-Migration)
  2. Identifizieren Sie die tatsächlichen Content-Muster (nicht was das CMS erzwungen hat)
  3. Entwerfen Sie Schemas auf Papier/Whiteboard zuerst
  4. Bauen Sie Schemas im Code
  5. Importieren Sie einen kleinen Test-Batch (50-100 Elemente)
  6. Lassen Sie Editoren die Studio-Erfahrung testen
  7. Iterieren Sie über Schemas vor vollständiger Migration

Schritte 5-7 sind kritisch und werden oft übersprungen. Wir haben mehr über Content-Modeling-Ansätze in unseren Headless CMS Entwicklungsarbeiten geschrieben.

Data Migration Strategien und Tools

Wesentliche Tools

  • @sanity/client: Der offizielle JavaScript Client zum Lesen/Schreiben von Sanity-Daten
  • @sanity/block-tools: Konvertiert HTML zu Portable Text
  • sanity dataset import/export: CLI Tools für vollständige Dataset-Operationen
  • ndjson: Sanity verwendet zeilengetrennte JSON für Importe — werden Sie damit vertraut
  • jsdom oder htmlparser2: Für HTML-Parsing während Rich Text Konvertierung

Migration Architektur

Ich strukturiere jede Migration als eine Pipeline mit vier Stufen:

Extract → Transform → Load → Validate

Jede Stufe ist ein separates Script. Dies ist wichtig, weil Sie die Migration mehrfach ausführen werden — typischerweise 5-10 Mal vor dem finalen Production Run. Mit separaten Stufen können Sie nur die Teile neu ausführen, die Fehlerbereinigung benötigen.

# Extract
node scripts/extract-wordpress.js > data/raw-posts.ndjson

# Transform
node scripts/transform-posts.js < data/raw-posts.ndjson > data/sanity-posts.ndjson

# Load
sanity dataset import data/sanity-posts.ndjson production --replace

# Validate
node scripts/validate-migration.js

Umgang mit Assets

Bilder und Dateien sind immer der langsamste Teil. Sanity's Asset-Pipeline ist gut, aber das Hochladen von 10.000 Bildern braucht Zeit. Tipps:

  • Laden Sie Assets zuerst hoch, behalten Sie eine Zuordnung von alten URLs zu neuen Sanity Asset-IDs
  • Verwenden Sie parallele Uploads (aber respektieren Sie Rate Limits — 25 Anfragen/Sek für den Growth-Plan)
  • Überprüfen Sie Bilddimensionen und Formate vor dem Upload
  • Migrieren Sie nicht Thumbnail-Größen — Sanity generiert diese spontan über sein Image-CDN

Die versteckten Kosten, über die keiner spricht

Lassen Sie mich ehrlich mit Ihnen über Kosten sprechen, die in der typischen Migrations-Schätzung nicht auftauchen.

URL Redirects

Wenn Sie Ihren Frontend ändern (was Sie wahrscheinlich tun, wenn Sie zu einem Headless CMS wechseln), benötigen Sie Redirect-Zuordnung. Jede. Einzelne. URL. Für SEO ist dies nicht verhandelbar. Eine Seite mit 5.000 Seiten benötigt 5.000 Redirect-Regeln. Tools wie next.config.js Redirects oder Vercel's _redirects Datei können das handhaben, aber jemand muss die Zuordnung bauen.

SEO Metadaten Migration

Yoast SEO-Daten von WordPress. Metatag-Modul-Daten von Drupal. Contentful's SEO-Felder. Das muss alles überkommen. Custom Meta Titles, Descriptions, Open Graph Images, Canonical URLs, Structured Data — es ist ein Projekt innerhalb des Projekts.

Editor Training und Dokumentation

Budgetieren Sie mindestens 2-4 Tage. Sanity Studio ist intuitiv, aber es ist anders als das, was Ihre Editoren kennen. Wir erstellen typischerweise benutzerdefinierte Studio-Dokumentation mit Screenshots und nehmen 3-5 Walkthrough-Videos auf.

Frontend Entwicklung

Dies ist der Elefant im Zimmer. Die Migration von Content zu Sanity ist nur die Hälfte des Projekts. Sie benötigen auch einen Frontend, der den Content konsumiert. Egal ob Sie Next.js, Astro oder ein anderes Framework verwenden, der Frontend-Build ist oft 50-70% der Gesamtprojektkosten. Schauen Sie sich unsere Arbeiten mit Next.js und Astro an, wenn Sie Frontend-Optionen evaluieren.

Zeitplan und Budget Vergleich

Basierend auf Projekten, die wir 2024-2025 abgeschlossen haben:

Migrationspfad Content-Volumen Komplexität Zeitplan Budget Range
WordPress → Sanity < 1.000 Seiten Niedrig 3-5 Wochen $8K-$15K
WordPress → Sanity 1.000-10.000 Seiten Mittel 6-10 Wochen $15K-$35K
WordPress → Sanity 10.000+ Seiten Hoch 10-16 Wochen $35K-$75K
Contentful → Sanity < 5.000 Einträge Niedrig-Mittel 3-5 Wochen $7K-$18K
Contentful → Sanity 5.000-20.000 Einträge Mittel 5-8 Wochen $18K-$40K
Drupal → Sanity < 2.000 Nodes Mittel 5-8 Wochen $12K-$25K
Drupal → Sanity 2.000-15.000 Nodes Hoch 8-14 Wochen $25K-$60K
Drupal 7 → Sanity Beliebig Sehr Hoch 10-20 Wochen $35K-$90K

Hinweis: Diese Ranges beinhalten nur Content-Migration. Frontend-Entwicklung ist zusätzlich. Kontaktieren Sie uns unter /pricing für projektspezifische Schätzungen.

Diese Zahlen beinhalten Content Modeling, Migration Scripting, Datenvalidation und grundlegendes Editor Training. Sie beinhalten nicht Frontend-Entwicklung, Design oder laufende Wartung.

Post-Migration Checkliste

Hier ist die Checkliste, die ich bei jeder Migration verwende:

  • Alle Content Types migriert und verifiziert
  • Alle Referenzen/Beziehungen intakt
  • Alle Bilder und Dateien hochgeladen und korrekt verlinkt
  • Rich Text Content renderiert korrekt (auf gebrochene Formatierung prüfen)
  • URL Redirects vorhanden und getestet
  • SEO-Metadaten migriert (Titel, Descriptions, OG-Daten)
  • XML Sitemap regeneriert
  • Search Console mit neuem Sitemap aktualisiert
  • Analytics Tracking bewahrt
  • Editor-Konten erstellt und Berechtigungen gesetzt
  • Editor Training abgeschlossen
  • Content Preview (Draft Mode) funktionierend
  • Webhooks konfiguriert für Build-Trigger
  • Backup von Source CMS-Daten archiviert
  • DNS-Änderungen geplant (falls zutreffend)
  • Performance Baseline gemessen
  • 404 Monitoring für erste 30 Tage eingerichtet

Dieser letzte Punkt ist wichtig. Egal wie gründlich Ihre Redirect-Zuordnung ist, einige URLs werden durchrutschen. Überwachen Sie Ihre 404s aggressiv für den ersten Monat.

FAQ

Wie lange dauert eine typische WordPress zu Sanity Migration?

Für eine Standard-WordPress-Seite mit unter 2.000 Beiträgen und unkomplizierten Custom Fields rechnen Sie mit 4-8 Wochen. Das beinhaltet Content Modeling, Migration Scripting, Datenvalidation und Editor Training. Seiten mit komplexen Gutenberg Blöcken, WooCommerce oder mehrsprachigem Content können 10-16 Wochen dauern. Das Content-Volumen ist weniger wichtig als die Komplexität Ihrer Content Types.

Kann ich von Contentful zu Sanity migrieren, ohne Daten zu verlieren?

Ja, und es ist tatsächlich der sauberste Migrationspfad unter den drei, die ich hier behandle. Beide Plattformen verwenden strukturierte, JSON-basierte Content, sodass die Zuordnung relativ direkt ist. Rich Text benötigt Konvertierung von Contentful's Format zu Portable Text, und Referenzen benötigen Remapping, aber Sie sollten keine Daten verlieren. Ich empfehle, die Migration zuerst gegen einen Staging Dataset zu laufen und einen gründlichen Content-Vergleich durchzuführen, bevor Sie umschalten.

Was passiert mit meinen SEO Rankings während einer CMS Migration?

Dies ist die Frage, die Marketing-Direktoren nachts wach hält. Wenn Sie Redirects richtig handhaben, wo möglich Ihre URL-Struktur beibehalten und alle SEO-Metadaten migrieren, sollten Sie minimale Auswirkungen sehen. Googles eigene Dokumentation sagt, dass ordnungsgemäß umgeleitete Migrationen möglicherweise einen vorübergehenden Rückgang von 2-4 Wochen sehen, bevor sie sich erholen. Das Schlüsselwort ist „ordnungsgemäß". Die Redirect-Zuordnung überspringen und Sie werden Ihre Rankings zum Absturz bringen. Wir haben das schon gesehen.

Ist Sanity für Enterprise-Nutzung billiger als Contentful?

In den meisten Fällen ja — manchmal erheblich. Sanity's Growth-Plan zu $99/Monat deckt ab, was Sie Contentful's $300/Monat Team-Plan bräuchten. Bei Enterprise-Skalierung wird der Unterschied größer. Contentful's Premium-Pricing ist nicht öffentlich gelistet, aber läuft typischerweise $2.000-$4.000+/Monat. Sanity Enterprise-Pricing ist auch benutzerdefiniert, läuft aber generell niedriger für gleichwertige Nutzung. Der echte Kostenunterschied liegt bei API-Aufrufen — Sanity's enthaltene Limits sind großzügiger.

Sollte ich meine Drupal 7 Seite zu Sanity migrieren oder zuerst zu Drupal 10 upgraden?

Gehen Sie direkt zu Sanity. Eine Migration von Drupal 7 zu Drupal 10 ist fast so viel Arbeit wie eine Migration zu einem anderen CMS komplett — die Architektur hat sich zwischen Versionen so dramatisch verändert. Wenn Sie bereits in eine Major-Migration investieren, könnten Sie genausogut zu der Plattform wechseln, auf der Sie langfristig sein wollen. Die einzige Ausnahme: Wenn Ihr Team tief in das Drupal-Ökosystem investiert ist und nur modernisieren will, ist Drupal 10 mit einem Headless Frontend ein gültiger Pfad.

Muss ich meinen Frontend neu bauen, wenn ich zu Sanity migriere?

Wenn Sie von einem monolithischen CMS wie WordPress oder Drupal kommen, ja — Sie benötigen einen neuen Frontend, da Sanity Headless ist. Dies ist normalerweise der größere Teil des Projekts. Wenn Sie von Contentful kommen, können Sie oft Ihren vorhandenen Frontend mit modifizierten API-Aufrufen wiederverwenden, besonders wenn Sie bereits Next.js oder ein ähnliches Framework verwenden. Wir handhaben sowohl die CMS-Migration als auch Frontend-Builds als integrierte Projekte.

Kann ich mein altes CMS und Sanity während der Migration parallel laufen lassen?

Absolut, und ich empfehle es. Lassen Sie beide Systeme für 2-4 Wochen nach Ihrer ersten Migration laufen. Editoren können weiterhin im alten CMS arbeiten, während Sie Daten in Sanity validieren. Frieren Sie einfach Content im alten System vor Ihrem finalen Migration Run ein — Sie wollen kein sich bewegendes Ziel verfolgen. Einige Teams legen einen "Content Freeze" 48 Stunden vor dem finalen Cutover fest.

Was ist der größte Fehler, den Teams bei einer Sanity Migration machen?

Versuchen, ihre alte CMS-Struktur genau in Sanity zu replizieren. Ich sehe das ständig. Teams kommen von WordPress und versuchen, WordPress-förmige Schemas in Sanity zu bauen — generische "Page" Types mit flexiblen Layouts statt purpose-built Content Types. Sanity's Stärke ist strukturierter Content. Nutzen Sie die Migration als Gelegenheit, Ihren Content richtig zu modellieren. Budgetieren Sie eine zusätzliche Woche für Content Modeling. Es wird Ihnen Monate Schmerz später sparen. Wenn Sie Anleitung dazu benötigen, kontaktieren Sie uns — Content Modeling ist eines der Dinge, auf die wir in Migrations-Projekten die meiste Zeit verwenden.