Votre équipe valide le passage à Sanity. Vous exportez 80 000 articles WordPress, lancez une instance Studio, et découvrez que la moitié de vos champs meta suivent trois schémas différents — et que personne n'a documenté la logique de taxonomie personnalisée qui alimentait toute la navigation de votre site. J'ai réalisé 40+ migrations vers Sanity au cours des trois dernières années. Certaines se sont fermées en deux semaines. D'autres se sont étirées sur trois mois et m'ont fait reconsidérer chaque décision qui m'a menée au freelance. La différence n'a jamais porté sur le fait que vous quittiez WordPress, Contentful ou Drupal. Elle s'est réduite à trois choses : l'honnêteté avec laquelle vous aviez défini votre modèle de contenu en amont, si vous aviez traité la cartographie des champs comme une architecture ou comme du travail superficiel, et si quelqu'un de votre équipe avait admis ne pas comprendre comment votre ancien CMS fonctionnait réellement. Ce playbook vous guide à travers chaque décision qui détermine si votre migration est un sprint propre ou un déploiement qui s'éternise — et vous montre les listes de contrôle exactes, les scripts et les modèles mentaux qui séparent les deux.

Ceci est le guide que j'aurais aimé avoir quand j'ai commencé à faire des migrations CMS. Il couvre le passage de WordPress, Contentful et Drupal vers le monde alimenté par GROQ de Sanity. Je vais être franc à propos de ce où Sanity excelle, où cela vous frustrera, et à quoi ressemblent les vrais délais.

Table des matières

Playbook de Migration Sanity : Passage de WordPress, Contentful ou Drupal

Pourquoi les équipes passent à Sanity en 2026

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

Les sites WordPress atteignent des limites d'échelle autour de 50 000+ éléments de contenu avec des types de posts personnalisés complexes. Le modèle tarifaire de Contentful commence à serrer au niveau entreprise — nous avons vu des équipes faisant 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 2026.

Le modèle tarifaire de Sanity est véritablement plus prévisible pour la plupart des équipes. L'offre gratuite couvre jusqu'à 100 K requêtes API/mois et 500 K actifs. Le plan Growth à 99 $/mois/projet vous donne 2,5 M requêtes API et 1 M actifs. Pour comparaison, le plan Team de Contentful coûte 300 $/mois et le plan Premium de Contentful peut facilement dépasser 2 000 $/mois.

Mais voici mon avis honnête : si votre CMS actuel fonctionne bien et que votre équipe est productive, ne faites pas de migration juste parce que Sanity est plus nouveau ou cool. Les migrations coûtent toujours plus cher que vous ne le pensez.

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

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

Inventaire du contenu

Documentez chaque type de contenu, chaque champ, chaque relation. J'utilise un tableur 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é personnalisée (codes courts, widgets, intégrations)
  • Date de dernière modification
  • Toujours pertinent ? (Oui/Non/Peut-être)

Vous serez choqués par la quantité de contenu mort. Lors d'une migration WordPress, un client avait 12 000 articles. Après l'audit, seulement 4 200 étaient encore pertinents. C'est 65 % de moins de contenu à migrer, tester et valider.

Cartographie des dépendances techniques

Listez chaque plugin, module ou intégration que votre CMS actuel utilise. 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 fera économiser des semaines de surprises à l'avenir.

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

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

Migration de WordPress vers Sanity

WordPress est la source CMS la plus courante à partir de laquelle nous migrons. C'est aussi la plus délicate, parce que WordPress n'est pas seulement un CMS — c'est une plateforme d'application entière sur laquelle les gens ont bolonné tout.

Ce qui se transfère proprement

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

Ce qui devient compliqué

  • Blocs Gutenberg : Chaque type de bloc a besoin d'un type de bloc personnalisé Portable Text correspondant ou d'un type d'objet Sanity. Si vous avez 15+ blocs Gutenberg personnalisés, budgétisez du temps significatif ici.
  • Codes courts : Ceux-ci ont besoin d'être analysés, interprétés et convertis en annotations Portable Text ou en blocs personnalisés. Les codes courts de WPBakery et Elementor sont particulièrement pénibles.
  • Contenu généré par un plugin : Les produits WooCommerce, les données Yoast SEO, les champs de répétition ACF — chacun nécessite une logique de migration personnalisée.
  • Médiathèque : WordPress stocke plusieurs tailles d'image. Sanity gère les transformations d'image à la volée, il vous suffit d'avoir les originaux. Mais trouver les originaux dans un dossier wp-uploads désordonné ? Amusant.

Approche de script de migration

J'utilise généralement un script Node.js qui utilise l'API REST WordPress et écrit dans l'API de mutation 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 où se situe 80 % de la complexité. J'utilise le paquet @sanity/block-tools combiné avec jsdom pour l'analyse HTML. Il gère bien l'HTML de base, mais les éléments personnalisés et les codes courts ont besoin de gestionnaires individuels.

Délais réalistes

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

Playbook de Migration Sanity : Passage de WordPress, Contentful ou 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 enrichi Rich Text (basé sur JSON) Portable Text (basé sur JSON)
Modélisation du contenu Interface web Schémas définis par code
Langage de requête GraphQL / REST GROQ (+ GraphQL)
Localisation Champ intégré au niveau du champ Plugin ou personnalisé
Références Liens (Entrée/Actif) Références avec types
Webhooks Oui Oui
Gestion des actifs CDN intégré Sanity CDN + hotspot/crop
Tarification (niveau intermédiaire) ~300 $/mois (Team) 99 $/mois (Growth)

Conversion du texte enrichi

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 des types de contenu au schéma

Les types de contenu de Contentful se mappent assez directement aux types de documents et d'objets Sanity. Le plus grand changement est que les schémas Sanity sont définis dans le 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 de 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

Délais réalistes

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 m'amènent à me 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'aux os, et fonctionnant sur une infrastructure que personne ne comprend pleinement.

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 pas 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édia : Le système de média de Drupal 9/10 est plus complexe que celui de WordPress. Plusieurs types de média, entités média réutilisables et configurations de champs de fichier qui doivent tous être mappées.
  • 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 devrez utiliser le plugin @sanity/document-internationalization ou une approche au niveau du champ.

Approche de migration

Je préfère utiliser le module JSON:API de Drupal (inclus dans le cœur de Drupal 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 la base de données directement. Le schéma de base de données de Drupal 7 est... une expérience. Les tables field_data_* hantent vos rêves.

Délais réalistes

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 n'exagère pas.

Modélisation du contenu : Bien définir vos schémas

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

Erreurs courantes de modélisation

  1. Créer un mappage de champ 1:1 : Ce n'est pas parce que WordPress avait un champ personnalisé « sous-titre » que Sanity en a besoin. Peut-être qu'il devrait faire partie d'un objet structuré « héros ».
  2. Sur-imbrication des objets : Sanity vous permet d'imbriquer les objets profondément. Résistez à l'envie. Les schémas plats-ish sont plus faciles à interroger avec GROQ et plus faciles pour les éditeurs.
  3. Ignorer la puissance de Portable Text : Ne jetez pas simplement le HTML dans un seul champ de texte. Concevez des types de bloc personnalisés qui correspondent à vos modèles de contenu. Un bloc « légende », un bloc « extrait de code », un bloc « image avec légende » — ceux-ci améliorent la vie des éditeurs.

Processus de conception de schéma

Je suis cet ordre :

  1. Audit du contenu existant (fait dans la pré-migration)
  2. Identification des modèles de contenu réels (pas ceux que le CMS a imposés)
  3. Conception des schémas sur papier/whiteboard d'abord
  4. Construction des schémas dans le code
  5. Importation d'un petit lot de test (50-100 éléments)
  6. Les éditeurs testent l'expérience Studio
  7. Itération sur les schémas avant la migration complète

Les étapes 5-7 sont critiques et souvent sautées. Nous avons écrit davantage sur les approches de modélisation de contenu dans notre travail de développement CMS headless.

Stratégies et outils de migration des données

Outils essentiels

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

Architecture de migration

Je structure chaque migration en tant que pipeline avec quatre étapes :

Extraire → Transformer → Charger → Valider

Chaque étape est un script séparé. Cela importe parce que vous exécuterez la migration plusieurs fois — généralement 5-10 fois avant la dernière exécution en production. Avoir des étapes séparées signifie que vous ne pouvez réexécuter que les parties qui nécessitent des corrections.

# 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 d'abord les actifs, maintenez un mappage des anciennes URL aux nouveaux 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 vignettes — Sanity les génère à la volée via son CDN d'images

Les coûts cachés dont personne ne parle

Soyez direct à propos des coûts qui n'apparaissent pas dans l'estimation de migration type.

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. Unique. Pour le référencement, 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 le gérer, 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 être transféré. Titres méta personnalisés, descriptions, images Open Graph, URL canoniques, données structurées — c'est un projet dans le projet.

Formation des éditeurs et documentation

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

Développement frontend

C'est l'éléphant dans la pièce. La migration de 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 compilation frontend est souvent 50-70 % du coût total du projet. Consultez notre travail avec Next.js et Astro si vous évaluez les options frontend.

Comparaison des délais et budgets

Basé sur les projets que nous avons complétés récemment :

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

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

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

Liste de contrôle post-migration

Voici la liste de contrôle que j'utilise à chaque migration :

  • Tous les types de contenu migrés et vérifiés
  • Toutes les références/relations intactes
  • Toutes les images et tous les fichiers téléchargés et correctement liés
  • Le contenu de texte enrichi s'affiche correctement (vérifiez la mise en forme cassée)
  • Redirections d'URL en place et testées
  • Métadonnées SEO migrées (titres, descriptions, données OG)
  • Sitemap XML régénéré
  • Console de recherche mise à jour avec nouveau sitemap
  • Suivi Analytics préservé
  • Comptes d'éditeur créés et autorisations définies
  • Formation des éditeurs complétée
  • Aperçu du contenu (mode brouillon) fonctionnant
  • Webhooks configurés pour les déclencheurs de compilation
  • Sauvegarde des données du CMS source archivée
  • Changements DNS prévus (le cas échéant)
  • Baseline de performance mesurée
  • Surveillance des 404 configurée pour les 30 premiers jours

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

FAQ

Combien de temps prend généralement une migration 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 du contenu, la rédaction du 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 importe 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 un contenu structuré basé sur JSON, de sorte que le mappage est relativement direct. Le texte enrichi doit être converti du format Contentful au Portable Text, et les références doivent être remappées, mais vous ne devriez perdre aucune donnée. Je recommande d'exécuter d'abord la migration par rapport à un ensemble de données de staging et de faire une comparaison de contenu approfondie avant le basculement.

Qu'advient-il de mes classements SEO lors d'une migration CMS ?

C'est la question qui tient les directeurs du 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 documentation de Google elle-même dit que les migrations correctement redirigées peuvent voir une baisse temporaire de 2-4 semaines avant de se rétablir. Le mot clé est « correctement ». Ignorez le mappage de redirection et vous couleriez vos classements. Nous l'avons vu arriver.

Sanity est-il moins cher que Contentful pour un usage en entreprise ?

Dans la plupart des cas, oui — parfois considérablement. Le plan Growth de Sanity à 99 $/mois couvre ce que vous utiliseriez pour le plan Team de Contentful à 300 $/mois. À l'échelle de l'entreprise, la différence devient plus grande. La tarification Premium de Contentful n'est pas publiquement listée mais s'exécute généralement à 2 000-4 000 $/mois+. La tarification Sanity Enterprise est également personnalisée, mais s'avère généralement être inférieure pour une utilisation équivalente. La vraie 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. La migration de Drupal 7 à Drupal 10 est presque autant de travail que de migrer vers un CMS différent — l'architecture a changé tellement entre les versions. Si vous investissez déjà dans une migration majeure, vous pourriez aussi bien passer à la plateforme sur laquelle vous voulez vraiment être à long terme. La seule exception : si votre équipe est profondément investie dans l'écosystème Drupal et veut simplement 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 créer 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 CMS et les compilations frontend en tant que projets intégrés.

Puis-je faire fonctionner mon ancien CMS et Sanity en parallèle lors de 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 tandis que vous validez les données dans Sanity. Gellez simplement le contenu dans l'ancien système avant votre dernière exécution de migration — vous ne voulez pas poursuivre une cible mouvante. Certaines équipes fixent une date « gel de contenu » 48 heures avant le basculement final.

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

Essayer de reproduire leur ancienne structure CMS exactement 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 « page » génériques avec des mises en page flexibles au lieu de types de contenu spécialement construits. La force de Sanity est le contenu structuré. Utilisez la migration comme une occasion de modéliser votre contenu correctement. Passez une semaine supplémentaire sur la modélisation du contenu. Cela vous fera économiser des mois de douleur plus tard. Si vous voulez des conseils sur cela, contactez-nous — la modélisation du contenu est l'une des choses sur lesquelles nous passons le plus de temps dans les projets de migration.