J'ai migré environ 40 projets vers Sanity au cours des trois dernières années. Certains ont été des sprints de deux semaines propres. D'autres se sont transformés en marathons de trois mois qui m'ont fait remettre en question mes choix de carrière. La différence provient presque jamais du CMS source — elle dépend de la préparation, des décisions de modélisation de contenu, et de l'honnêteté vis-à-vis de ce à quoi on s'engage réellement.

Ceci est le guide que j'aurais aimé avoir quand j'ai commencé à faire des migrations de CMS. Il couvre le passage de WordPress, Contentful et Drupal vers le monde alimenté par GROQ de Sanity. Je vais être direct sur les domaines où Sanity excelle, où elle vous frustrera, et à quoi ressemblent réellement les calendriers.

Table des matières

Sanity Migration Playbook: Moving from WordPress, Contentful, or Drupal

Pourquoi les équipes passent à Sanity en 2025

Commençons par les évidences. L'édition collaborative en temps réel de Sanity, le Studio personnalisable et l'approche du contenu structuré sont vraiment bons. Mais la raison pour laquelle la plupart des équipes nous contactent à propos d'une migration n'est pas parce qu'elles ont lu un article de blog sur les fonctionnalités de Sanity. C'est parce que quelque chose s'est cassé.

Les sites WordPress frappent les murs de scalabilité autour de 50 000+ contenus avec des types de publication personnalisés complexes. Le modèle de tarification de Contentful commence à presser à l'échelle entreprise — nous avons vu des équipes faire face à des factures de 3 500+ $/mois pour ce qui revient à une API de contenu. Les équipes Drupal ne trouvent plus de développeurs, du moins pas ceux qui veulent travailler avec les templates PHP en 2025.

Le modèle de tarification de Sanity est vraiment plus prévisible pour la plupart des équipes. Le niveau gratuit couvre jusqu'à 100K appels API/mois et 500K actifs. Le plan Growth à 99 $/mois/projet vous donne 2,5M d'appels API et 1M actifs. En comparaison, le plan Team de Contentful coûte 300 $/mois et le niveau Premium de Contentful peut facilement dépasser 2 000 $/mois.

Mais voici mon avis honnête : si votre CMS actuel fonctionne bien et votre équipe est productive, ne migrez pas juste parce que Sanity est plus nouveau ou plus cool. Les migrations coûtent toujours plus qu'on ne le pense.

Audit pré-migration : l'étape que tout le monde saute

Avant d'écrire une seule ligne de code de migration, vous devez faire un audit de contenu. Pas un scan rapide — un véritable audit. Voici à quoi cela ressemble :

Inventaire de contenu

Documentez chaque type de contenu, chaque champ, chaque relation. J'utilise une feuille de calcul avec ces colonnes :

  • Nom du type de contenu
  • Nombre total d'éléments
  • Champs (avec types)
  • Relations avec d'autres types de contenu
  • Pièces jointes médias (nombre et taille totale)
  • Fonctionnalités personnalisées (shortcodes, widgets, embeds)
  • Date de dernière modification
  • Toujours pertinent ? (Oui/Non/Peut-être)

Vous serez choqué de voir combien de contenu est du poids mort. Sur une migration WordPress, un client avait 12 000 articles. Après l'audit, seulement 4 200 étaient toujours pertinents. C'est 65% de contenu en moins à migrer, tester et valider.

Cartographie des dépendances techniques

Listez tous les plugins, modules ou intégrations utilisés par votre CMS actuel. Pour chacun, déterminez :

  1. Sanity peut-il gérer cela nativement ?
  2. Y a-t-il un plugin Sanity pour cela ?
  3. Avons-nous besoin de construire une solution personnalisée ?
  4. Pouvons-nous abandonner cela entièrement ?

Cette cartographie seule vous économisera des semaines de surprises plus tard.

Évaluation de la préparation de l'équipe

Sanity Studio est basé sur React. Vos éditeurs de contenu auront besoin d'une formation. Vos développeurs devront apprendre GROQ (ou utiliser GraphQL, bien que GROQ soit là où Sanity brille vraiment). Budgétez 1-2 semaines pour l'intégration de l'équipe — pas comme un élément facultatif, mais comme un poste budgétaire.

Migration de WordPress vers Sanity

WordPress est le CMS source le plus courant duquel nous migrons. C'est aussi le plus délicat, car WordPress n'est pas seulement un CMS — c'est toute une plateforme d'application sur laquelle les gens ont boulonné tout.

Ce qui se transfère correctement

  • Articles et pages (contenu de base)
  • Catégories et tags
  • Images mises en avant
  • Données d'auteur
  • Champs personnalisés basiques (ACF, Meta Box)

Ce qui devient compliqué

  • Blocs Gutenberg : Chaque type de bloc nécessite un bloc personnalisé Portable Text correspondant ou un type d'objet. Si vous avez 15+ blocs Gutenberg personnalisés, budgétez du temps significatif ici.
  • Shortcodes : Ceux-ci doivent être analysés, interprétés et convertis en annotations Portable Text ou blocs personnalisés. Les shortcodes WPBakery et Elementor sont particulièrement douloureux.
  • Contenu généré par les plugins : Produits WooCommerce, données Yoast SEO, champs répétiteurs ACF — chacun nécessite une logique de migration personnalisée.
  • Bibliothèque multimédia : WordPress stocke plusieurs tailles d'images. Sanity gère les transformations d'images à la volée, donc vous n'avez besoin que des originaux. Mais trouver les originaux dans un dossier wp-uploads désordonné ? Du pur plaisir.

Approche du script de migration

J'utilise généralement un script Node.js qui accède à l'API REST de WordPress et écrit sur l'API de mutation de Sanity :

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 requires HTML-to-Portable-Text conversion
      body: await convertToPortableText(post.content.rendered),
    })
  }

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

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

La fonction convertToPortableText est là où vivent 80% de la complexité. J'utilise le package @sanity/block-tools combiné avec jsdom pour l'analyse HTML. Il gère bien le HTML de base, mais les éléments personnalisés et les shortcodes ont besoin de gestionnaires individuels.

Calendrier réaliste

Pour un site WordPress typique avec 500-2 000 articles, des champs personnalisés standards et une poignée de types de publication personnalisés : 4-8 semaines incluant la modélisation de contenu, le script de migration, la validation et la formation des éditeurs.

Sanity Migration Playbook: Moving from WordPress, Contentful, or Drupal - architecture

Migration de Contentful vers Sanity

Contentful vers Sanity est en fait le chemin de migration le plus fluide des trois. Pourquoi ? Parce que les deux sont des plateformes de contenu structuré avec des modèles mentaux similaires. Votre contenu est déjà dans un CMS headless avec des types de contenu et des champs définis.

Différences clés à prendre en compte

Fonctionnalité Contentful Sanity
Texte riche Rich Text (basé sur JSON) Portable Text (basé sur JSON)
Modélisation de contenu Interface web Schémas définis en code
Langage de requête GraphQL / REST GROQ (+ GraphQL)
Localisation Intégrée au niveau des champs Plugin ou personnalisé
Références Liens (Entry/Asset) Références avec types
Webhooks Oui Oui
Gestion des actifs CDN intégré CDN Sanity + hotspot/crop
Tarification (milieu de gamme) ~300 $/mo (Team) 99 $/mo (Growth)

Conversion de texte riche

Le Rich Text de Contentful et le Portable Text de Sanity sont tous deux basés sur JSON, ce qui est excellent. Mais ils ont des structures différentes. Vous devrez écrire un transformateur :

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':
        // Map to your custom Portable Text type
        return mapEmbeddedEntry(node)
      // ... handle all node types
    }
  }).filter(Boolean)
}

Cartographie type de contenu vers schéma

Les types de contenu Contentful sont mappés assez directement aux types de document et d'objet Sanity. Le plus grand changement est que les schémas Sanity sont définis en code (JavaScript/TypeScript), pas dans une interface web. C'est en fait un énorme avantage — votre modèle de contenu vit dans le contrôle de version.

Utilisez l'API de gestion Contentful pour exporter votre modèle de contenu, puis écrivez un script qui génère des fichiers de schéma Sanity :

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

Calendrier réaliste

Pour un espace Contentful avec 10-20 types de contenu et 5 000-10 000 entrées : 3-5 semaines. C'est plus rapide parce que vous pensez déjà en contenu structuré.

Migration de Drupal vers Sanity

Les migrations Drupal sont celles qui me font verser un deuxième café. Non pas parce que Drupal est mauvais — c'est un système puissant. Mais les sites Drupal ont tendance à être anciens, personnalisés jusqu'à la perfection, et fonctionnent sur une infrastructure que personne ne comprend vraiment complètement.

Les défis spécifiques à Drupal

  • Types de contenu avec 50+ champs : Drupal rend facile l'ajout de champs. Trop facile. J'ai vu des types de contenu avec 80 champs, dont la moitié ne sont jamais utilisés.
  • Références de termes de taxonomie : Le système de taxonomie de Drupal est flexible mais peut créer des hiérarchies profondément imbriquées qui doivent être aplaties pour Sanity.
  • Module Paragraphs : Si le site utilise Drupal Paragraphs (et la plupart des sites Drupal modernes le font), chaque type de paragraphe devient un type de bloc Portable Text ou un objet Sanity. C'est la plus grande tâche unique.
  • Entités médias : Le système média de Drupal 9/10 est plus complexe que celui de WordPress. Plusieurs types de médias, entités médias réutilisables et configurations de champs de fichiers doivent tous être mappés.
  • Contenu multilingue : Le système de traduction de Drupal est sophistiqué. Sanity n'a pas de localisation intégrée au même niveau — vous aurez besoin du plugin @sanity/document-internationalization ou d'une approche au niveau du champ.

Approche de migration

Je préfère utiliser le module JSON:API de Drupal (inclus dans Drupal core depuis 9.x) comme couche d'extraction :

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()
}

Pour les sites Drupal 7 plus anciens sans JSON:API, vous devrez peut-être interroger directement la base de données. Le schéma de base de données de Drupal 7 est... une expérience. Les tables field_data_* hanteront vos rêves.

Calendrier réaliste

Les migrations Drupal varient énormément. Un site Drupal 10 simple avec 5-10 types de contenu : 5-8 semaines. Un site Drupal 7 hérité avec 30+ types de contenu, Paragraphs et contenu multilingue : 8-16 semaines. Je ne plaisante pas.

Modélisation de contenu : bien faire ses schémas

Voici ce que la plupart des guides de migration ne vous diront pas : ne répliquez pas votre ancien modèle de contenu dans Sanity. C'est votre chance de corriger des années de dette de contenu accumulée.

Erreurs courantes de modélisation

  1. Créer un mappage de champs 1:1 : Juste parce que WordPress avait un champ personnalisé "sous-titre" ne signifie pas que Sanity en a besoin. Peut-être que cela devrait faire partie d'un objet "hero" structuré.
  2. Sur-imbriquer les objets : Sanity vous permet d'imbriquer les objets profondément. Résistez à l'envie. Les schémas à peu près plats sont plus faciles à interroger avec GROQ et plus faciles pour les éditeurs.
  3. Ignorer la puissance de Portable Text : Ne jetez pas simplement du HTML dans un seul champ de texte. Concevez des types de blocs personnalisés qui correspondent à vos modèles de contenu. Un bloc "callout", un bloc "code snippet", un bloc "image avec légende" — ceux-ci rendent la vie des éditeurs meilleure.

Processus de conception de schémas

Je suis cet ordre :

  1. Vérifier le contenu existant (fait pré-migration)
  2. Identifier les modèles de contenu réels (pas ce que le CMS a imposé)
  3. Concevoir les schémas sur papier/tableau blanc d'abord
  4. Construire les schémas en code
  5. Importer un petit lot de test (50-100 éléments)
  6. Faire tester l'expérience Studio par les éditeurs
  7. Itérer sur les schémas avant la migration complète

Les étapes 5-7 sont critiques et souvent ignorées. Nous avons écrit plus sur les approches de modélisation de contenu dans nos travaux de développement CMS headless.

Stratégies et outils de migration de données

Outils essentiels

  • @sanity/client : Le client JavaScript officiel pour lire/écrire des données Sanity
  • @sanity/block-tools : Convertit le HTML en Portable Text
  • sanity dataset import/export : Outils CLI pour les opérations de dataset complet
  • ndjson : Sanity utilise du JSON délimité par des retours à la ligne pour les importations — familiarisez-vous avec cela
  • jsdom ou htmlparser2 : Pour l'analyse HTML lors de la conversion de texte riche

Architecture de migration

Je structure chaque migration comme un pipeline à quatre étapes :

Extract → Transform → Load → Validate

Chaque étape est un script séparé. C'est important parce que vous exécuterez la migration plusieurs fois — généralement 5-10 fois avant la migration de production finale. Avoir des étapes séparées signifie que vous pouvez réexécuter seulement les parties qui ont besoin d'être corrigées.

# 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

Gestion des actifs

Les images et les fichiers sont toujours la partie la plus lente. Le pipeline d'actifs de Sanity est bon, mais télécharger 10 000 images prend du temps. Conseils :

  • Téléchargez les actifs d'abord, maintenez un mappage des anciennes URL vers les ID d'actif Sanity
  • Utilisez les téléchargements concurrents (mais respectez les limites de débit — 25 req/sec pour le plan Growth)
  • Vérifiez les dimensions et formats d'image avant le téléchargement
  • Ne migrez pas les tailles de miniatures — Sanity les génère à la volée via son CDN d'images

Les coûts cachés dont personne ne parle

Soyons direct avec vous sur les coûts qui ne figurent pas dans l'estimation de migration typique.

Redirections d'URL

Si vous changez votre frontend (ce que vous faites probablement si vous passez à un CMS headless), vous avez besoin d'un mappage de redirection. Chaque. URL. Simple. Pour le SEO, c'est non-négociable. Un site avec 5 000 pages a besoin de 5 000 règles de redirection. Des outils comme les redirections next.config.js ou le fichier _redirects de Vercel peuvent gérer cela, mais quelqu'un doit construire le mappage.

Migration des métadonnées SEO

Données Yoast SEO de WordPress. Données du module Metatag de Drupal. Champs SEO de Contentful. Tout cela doit venir. Titres de métadonnées personnalisés, descriptions, images Open Graph, URL canoniques, données structurées — c'est un projet dans le projet.

Formation et documentation des éditeurs

Budgétez 2-4 jours minimum. Sanity Studio est intuitif, mais c'est différent de ce que connaissent vos éditeurs. Nous créons généralement une documentation Studio personnalisée avec des captures d'écran et enregistrons 3-5 vidéos de parcours.

Développement frontend

C'est l'éléphant dans la pièce. Migrer le contenu vers Sanity n'est que la moitié du projet. Vous avez également besoin d'un frontend qui consomme le contenu. Que vous utilisiez Next.js, Astro ou un autre framework, la construction du frontend est souvent 50-70% du coût total du projet. Consultez nos travaux avec Next.js et Astro si vous évaluez les options de frontend.

Comparaison des calendriers et budgets

Basé sur les projets que nous avons complétés en 2024-2025 :

Chemin de migration Volume de contenu Complexité Calendrier Plage budgétaire
WordPress → Sanity < 1 000 pages Faible 3-5 semaines 8 000 $-15 000 $
WordPress → Sanity 1 000-10 000 pages Moyen 6-10 semaines 15 000 $-35 000 $
WordPress → Sanity 10 000+ pages Élevé 10-16 semaines 35 000 $-75 000 $
Contentful → Sanity < 5 000 entrées Faible-Moyen 3-5 semaines 7 000 $-18 000 $
Contentful → Sanity 5 000-20 000 entrées Moyen 5-8 semaines 18 000 $-40 000 $
Drupal → Sanity < 2 000 nœuds Moyen 5-8 semaines 12 000 $-25 000 $
Drupal → Sanity 2 000-15 000 nœuds Élevé 8-14 semaines 25 000 $-60 000 $
Drupal 7 → Sanity N'importe quel Très élevé 10-20 semaines 35 000 $-90 000 $

Note : Ces plages incluent uniquement la migration de contenu. Le développement frontend est supplémentaire. Contactez-nous à /pricing pour des estimations spécifiques au projet.

Ces chiffres incluent la modélisation de contenu, le script de migration, la validation des données et la formation de base des éditeurs. Ils n'incluent pas le développement frontend, le design ou la maintenance continue.

Checklist post-migration

Voici la checklist que j'utilise sur chaque migration :

  • Tous les types de contenu migrés et vérifiés
  • Toutes les références/relations intactes
  • Toutes les images et fichiers téléchargés et correctement liés
  • Le contenu en texte riche s'affiche correctement (vérifiez les formatages cassés)
  • Les redirections d'URL en place et testées
  • Les métadonnées SEO migrées (titres, descriptions, données OG)
  • Le sitemap XML régénéré
  • La console de recherche mise à jour avec le nouveau sitemap
  • Le suivi analytique préservé
  • Les comptes d'éditeur créés et les permissions définies
  • La formation des éditeurs complétée
  • L'aperçu du contenu (mode brouillon) fonctionnant
  • Les webhooks configurés pour les déclencheurs de build
  • La sauvegarde des données du CMS source archivée
  • Les changements DNS planifiés (le cas échéant)
  • La ligne de base des performances mesurée
  • Le suivi des 404 configuré pour les 30 premiers jours

Ce dernier point est important. Peu importe la rigueur de votre mappage de redirection, certaines URL passeront à travers. Surveillez agressivement vos 404 pendant le premier mois.

FAQ

Combien de temps dure une migration typique de WordPress vers Sanity ?

Pour un site WordPress standard avec moins de 2 000 articles et des champs personnalisés simples, attendez-vous à 4-8 semaines. Cela inclut la modélisation de contenu, le script de migration, la validation des données et la formation des éditeurs. Les sites avec des blocs Gutenberg complexes, WooCommerce ou du contenu multilingue peuvent prendre 10-16 semaines. Le volume de contenu compte moins que la complexité de vos types de contenu.

Puis-je migrer de Contentful vers Sanity sans perdre de données ?

Oui, et c'est en fait le chemin de migration le plus propre parmi les trois que je couvre ici. Les deux plateformes utilisent du contenu structuré et basé sur JSON, donc le mappage est relativement direct. Le texte riche doit être converti du format de Contentful au Portable Text, et les références doivent être remappées, mais vous ne devriez pas perdre de données. Je recommande d'exécuter d'abord la migration contre un dataset de staging et de faire une comparaison de contenu approfondie avant le basculement.

Qu'advient-il de mon classement SEO lors d'une migration CMS ?

C'est la question qui garde les directeurs marketing éveillés la nuit. Si vous gérez correctement les redirections, maintenez votre structure d'URL si possible et migrez toutes les métadonnées SEO, vous devriez voir un impact minimal. La propre documentation de Google dit qu'une migration correctement redirigée peut voir une baisse temporaire de 2-4 semaines avant récupération. Le mot clé est "correctement". Ignorez le mappage de redirection et vous tankerez vos classements. Nous l'avons vu arriver.

Sanity est-il moins cher que Contentful pour l'utilisation d'entreprise ?

Dans la plupart des cas, oui — parfois de manière significative. Le plan Growth de Sanity à 99 $/mois couvre ce dont vous auriez besoin avec le plan Team de Contentful à 300 $/mois. À grande échelle d'entreprise, la différence devient plus importante. La tarification Premium de Contentful n'est pas listée publiquement mais s'élève généralement à 2 000 $-4 000+$/mois. La tarification Sanity Enterprise est également personnalisée mais généralement moins chère pour une utilisation équivalente. La véritable différence de coût est dans les appels API — les limites incluses de Sanity sont plus généreuses.

Devrais-je migrer mon site Drupal 7 vers Sanity ou d'abord passer à Drupal 10 ?

Allez directement à Sanity. Migrer de Drupal 7 à Drupal 10 est presque autant de travail que migrer vers un CMS différent — l'architecture a changé de manière si dramatique entre les versions. Si vous investissez déjà dans une migration majeure, vous pourriez aussi bien passer à la plateforme que vous voulez vraiment utiliser à long terme. L'une des exceptions : si votre équipe est profondément investie dans l'écosystème Drupal et veut juste se moderniser, Drupal 10 avec un frontend headless est un chemin valide.

Dois-je reconstruire mon frontend lors de la migration vers Sanity ?

Si vous venez d'un CMS monolithique comme WordPress ou Drupal, oui — vous devrez avoir un nouveau frontend puisque Sanity est headless. C'est généralement la plus grande partie du projet. Si vous venez de Contentful, vous pouvez souvent réutiliser votre frontend existant avec des appels API modifiés, surtout si vous utilisez déjà Next.js ou un framework similaire. Nous gérons à la fois la migration du CMS et les constructions de frontend comme des projets intégrés.

Puis-je exécuter mon ancien CMS et Sanity en parallèle pendant la migration ?

Absolument, et je le recommande. Exécutez les deux systèmes pendant 2-4 semaines après votre migration initiale. Les éditeurs peuvent continuer à travailler dans l'ancien CMS pendant que vous validez les données dans Sanity. Gelé simplement le contenu dans l'ancien système avant votre exécution de migration finale — vous ne voulez pas chasser une cible mouvante. Certaines équipes mettent en place une date "gel du contenu" 48 heures avant le basculement final.

Quelle est la plus grande erreur que les équipes font lors d'une migration Sanity ?

Essayer de répliquer exactement sa structure ancien CMS dans Sanity. Je vois cela constamment. Les équipes viennent de WordPress et essaient de construire des schémas en forme de WordPress dans Sanity — des types de "page" génériques avec des mises en page flexibles au lieu de types de contenu construits à dessein. La force de Sanity est le contenu structuré. Utilisez la migration comme une opportunité de modeler votre contenu correctement. Passez une semaine supplémentaire sur la modélisation de contenu. Cela vous économisera des mois de douleur plus tard. Si vous voulez des conseils à ce sujet, contactez-nous — la modélisation de contenu est l'une des choses sur lesquelles nous passons le plus de temps dans les projets de migration.