지난 3년간 약 40개의 프로젝트를 Sanity로 마이그레이션했습니다. 깔끔하게 2주간 진행된 프로젝트도 있었고, 경력 선택을 의심하게 만드는 3개월 프로젝트도 있었습니다. 차이점은 거의 항상 원본 CMS에서 비롯되지 않습니다. 준비, 콘텐츠 모델링 결정, 그리고 실제로 무엇을 하려는지 정직하게 인정하는 것에서 비롯됩니다.

이것이 CMS 마이그레이션을 시작했을 때 원했던 가이드입니다. WordPress, Contentful, Drupal에서 Sanity의 GROQ 기반 세계로 이동하는 과정을 다룹니다. Sanity가 뛰어난 곳, 답답한 곳, 실제 일정이 어떤지에 대해 솔직하게 설명하겠습니다.

목차

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

팀들이 2025년 Sanity로 이동하는 이유

명백한 것부터 시작하겠습니다. Sanity의 실시간 협업 편집, 사용자 지정 가능한 Studio, 그리고 구조화된 콘텐츠 접근 방식은 정말 좋습니다. 하지만 대부분의 팀이 마이그레이션에 대해 연락하는 이유는 Sanity의 기능에 대한 블로그 포스트를 읽었기 때문이 아닙니다. 뭔가가 깨졌기 때문입니다.

WordPress 사이트는 복잡한 사용자 정의 포스트 타입과 함께 50,000개 이상의 콘텐츠로 확장 한계에 도달합니다. Contentful의 가격 모델은 엔터프라이즈 계층에서 압박을 받기 시작합니다. 콘텐츠 API에 불과한 것에 대해 월 $3,500 이상의 청구를 받는 팀들을 봤습니다. Drupal 팀은 더 이상 개발자를 찾을 수 없습니다. 2025년에 PHP 템플릿을 사용하고 싶어하는 개발자는 거의 없습니다.

Sanity의 가격 모델은 대부분의 팀에게 예측 가능합니다. 무료 계층은 월 100K API 요청과 500K 자산을 커버합니다. 월 $99인 Growth 플랜은 2.5M API 요청과 1M 자산을 제공합니다. 비교하자면 Contentful의 Team 플랜은 월 $300이고 Contentful의 Premium 계층은 쉽게 월 $2,000 이상이 될 수 있습니다.

하지만 솔직한 의견입니다: 현재 CMS가 잘 작동하고 팀이 생산적이라면 Sanity가 더 새롭거나 멋있다고 해서 마이그레이션하지 마세요. 마이그레이션은 항상 생각보다 비용이 더 듭니다.

사전 마이그레이션 감사: 모두가 건너뛰는 단계

마이그레이션 코드 한 줄을 작성하기 전에 콘텐츠 감사가 필요합니다. 빠른 스캔이 아닌 실제 감사입니다. 다음과 같이 보입니다:

콘텐츠 목록

모든 콘텐츠 타입, 모든 필드, 모든 관계를 문서화합니다. 다음 열이 있는 스프레드시트를 사용합니다:

  • 콘텐츠 타입 이름
  • 총 항목 수
  • 필드 (타입 포함)
  • 다른 콘텐츠 타입과의 관계
  • 미디어 첨부 (수량 및 총 크기)
  • 사용자 정의 기능 (단축코드, 위젯, 임베드)
  • 마지막 수정 날짜
  • 여전히 관련이 있습니까? (예/아니오/아마도)

죽은 무게인 콘텐츠가 얼마나 많은지 놀랄 것입니다. 한 WordPress 마이그레이션에서 클라이언트는 12,000개의 포스트가 있었습니다. 감사 후 4,200개만 관련이 있었습니다. 마이그레이션, 테스트 및 검증할 콘텐츠가 65% 적습니다.

기술 종속성 매핑

현재 CMS가 사용하는 모든 플러그인, 모듈 또는 통합을 나열합니다. 각각에 대해 다음을 결정합니다:

  1. Sanity가 이것을 기본으로 처리할 수 있습니까?
  2. Sanity 플러그인이 있습니까?
  3. 사용자 정의 솔루션을 구축해야 합니까?
  4. 이것을 완전히 삭제할 수 있습니까?

이 매핑 자체만으로도 앞으로의 놀람으로부터 몇 주를 절약할 수 있습니다.

팀 준비도 평가

Sanity Studio는 React 기반입니다. 콘텐츠 편집자는 교육이 필요합니다. 개발자는 GROQ를 배워야 합니다 (또는 GraphQL을 사용할 수 있지만, GROQ는 Sanity가 진정으로 빛나는 곳입니다). 팀 온보딩에 1-2주를 예산합니다. 선택 사항이 아니라 항목으로서 말입니다.

WordPress에서 Sanity로의 마이그레이션

WordPress는 우리가 마이그레이션하는 가장 일반적인 소스 CMS입니다. 또한 가장 까다로운데, WordPress는 단지 CMS가 아니라 사람들이 모든 것을 붙여 놓은 전체 애플리케이션 플랫폼이기 때문입니다.

깔끔하게 전달되는 것들

  • 포스트 및 페이지 (기본 콘텐츠)
  • 카테고리 및 태그
  • 추천 이미지
  • 작성자 데이터
  • 기본 사용자 정의 필드 (ACF, Meta Box)

복잡해지는 것들

  • Gutenberg 블록: 각 블록 타입은 대응하는 Sanity Portable Text 사용자 정의 블록 또는 객체 타입이 필요합니다. 15개 이상의 사용자 정의 Gutenberg 블록이 있다면 상당한 시간을 예산하세요.
  • 단축코드: 이들은 구문 분석되고, 해석되고, Portable Text 주석 또는 사용자 정의 블록으로 변환되어야 합니다. WPBakery 및 Elementor 단축코드는 특히 성가십니다.
  • 플러그인 생성 콘텐츠: WooCommerce 제품, Yoast SEO 데이터, ACF 반복자 필드 — 각각 사용자 정의 마이그레이션 로직이 필요합니다.
  • 미디어 라이브러리: WordPress는 여러 이미지 크기를 저장합니다. Sanity는 이미지 변환을 즉시 처리하므로 원본만 필요합니다. 하지만 지저분한 wp-uploads 폴더에서 원본을 찾기는? 재미있는 시간입니다.

마이그레이션 스크립트 접근 방식

일반적으로 WordPress REST API를 누르고 Sanity의 변경 API에 쓰는 Node.js 스크립트를 사용합니다:

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

convertToPortableText 함수는 복잡성의 80%가 있는 곳입니다. HTML 구문 분석을 위해 @sanity/block-tools 패키지와 jsdom을 결합하여 사용합니다. 기본 HTML을 잘 처리하지만 사용자 정의 요소 및 단축코드는 개별 처리기가 필요합니다.

현실적인 일정

표준 사용자 정의 필드와 몇 가지 사용자 정의 포스트 타입이 있는 500-2,000개 포스트를 가진 일반적인 WordPress 사이트의 경우: 4-8주 (콘텐츠 모델링, 마이그레이션 스크립팅, 검증, 편집자 교육 포함).

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

Contentful에서 Sanity로의 마이그레이션

Contentful에서 Sanity로의 마이그레이션은 실제로 세 가지 중 가장 부드러운 마이그레이션 경로입니다. 왜인가요? 둘 다 유사한 정신 모델을 가진 구조화된 콘텐츠 플랫폼이기 때문입니다. 콘텐츠는 이미 정의된 콘텐츠 타입 및 필드와 함께 헤드리스 CMS에 있습니다.

고려해야 할 주요 차이점

기능 Contentful Sanity
리치 텍스트 Rich Text (JSON 기반) Portable Text (JSON 기반)
콘텐츠 모델링 웹 UI 코드 정의 스키마
쿼리 언어 GraphQL / REST GROQ (+ GraphQL)
지역화 기본 제공 필드 레벨 플러그인 또는 사용자 정의
참조 Links (Entry/Asset) 타입을 포함한 참조
Webhooks 예 예
자산 처리 기본 제공 CDN Sanity CDN + hotspot/crop
가격 (중간 계층) ~$300/월 (Team) $99/월 (Growth)

리치 텍스트 변환

Contentful의 Rich Text와 Sanity의 Portable Text는 모두 JSON 기반이므로 좋습니다. 하지만 구조가 다릅니다. 변환기를 작성해야 합니다:

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

콘텐츠 타입에서 스키마로의 매핑

Contentful 콘텐츠 타입은 Sanity 문서 및 객체 타입에 상당히 직접 매핑됩니다. 가장 큰 변화는 Sanity 스키마가 코드(JavaScript/TypeScript)로 정의되어 웹 UI가 아니라는 점입니다. 이것은 실제로 엄청난 이점입니다. 콘텐츠 모델이 버전 제어에 생깁니다.

Contentful Management API를 사용하여 콘텐츠 모델을 내보낸 다음 Sanity 스키마 파일을 생성하는 스크립트를 작성합니다:

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

현실적인 일정

10-20개의 콘텐츠 타입과 5,000-10,000개 항목이 있는 Contentful 공간의 경우: 3-5주. 이미 구조화된 콘텐츠를 생각하고 있기 때문에 더 빠릅니다.

Drupal에서 Sanity로의 마이그레이션

Drupal 마이그레이션은 두 번째 커피를 부을 이유를 주는 것입니다. Drupal이 나쁘기 때문이 아닙니다. Drupal은 강력한 시스템입니다. 하지만 Drupal 사이트는 오래되고, 철저히 사용자 정의되어 있으며, 아무도 완전히 이해하지 못하는 인프라에서 실행되는 경향이 있습니다.

Drupal 특정 과제

  • 50개 이상의 필드를 가진 콘텐츠 타입: Drupal은 필드를 추가하기 쉽게 만듭니다. 너무 쉽습니다. 80개의 필드를 가진 콘텐츠 타입을 본 적이 있는데, 그 중 절반은 사용되지 않았습니다.
  • Taxonomy 항 참조: Drupal의 분류 시스템은 유연하지만 Sanity를 위해 평탄화해야 하는 깊게 중첩된 계층 구조를 만들 수 있습니다.
  • Paragraphs 모듈: 사이트가 Drupal Paragraphs를 사용하는 경우 (대부분의 최신 Drupal 사이트는 사용) 각 단락 타입은 Portable Text 블록 타입 또는 Sanity 객체가 됩니다. 이것이 가장 큰 단일 작업입니다.
  • 미디어 엔터티: Drupal 9/10의 미디어 시스템은 WordPress의 것보다 복잡합니다. 여러 미디어 타입, 재사용 가능한 미디어 엔터티, 파일 필드 구성 모두 매핑이 필요합니다.
  • 다국어 콘텐츠: Drupal의 번역 시스템은 정교합니다. Sanity는 같은 수준의 기본 지역화를 갖지 않습니다. @sanity/document-internationalization 플러그인 또는 필드 레벨 접근 방식이 필요합니다.

마이그레이션 접근 방식

Drupal의 JSON:API 모듈 (Drupal 9.x 이후 핵심에 포함)을 추출 레이어로 사용하는 것을 선호합니다:

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

JSON:API 없는 오래된 Drupal 7 사이트의 경우 데이터베이스를 직접 쿼리해야 할 수도 있습니다. Drupal 7의 데이터베이스 스키마는... 경험입니다. field_data_* 테이블은 당신의 악몽을 지배할 것입니다.

현실적인 일정

Drupal 마이그레이션은 매우 다양합니다. 5-10개의 콘텐츠 타입이 있는 간단한 Drupal 10 사이트: 5-8주. 30개 이상의 콘텐츠 타입, Paragraphs, 다국어 콘텐츠를 가진 레거시 Drupal 7 사이트: 8-16주. 과장하지 않습니다.

콘텐츠 모델링: 스키마 올바르게 만들기

대부분의 마이그레이션 가이드가 말하지 않을 점: Sanity에서 기존 콘텐츠 모델을 복제하지 마세요. 이것은 수년간의 누적된 콘텐츠 부채를 해결할 기회입니다.

일반적인 모델링 실수

  1. 1:1 필드 매핑 생성: WordPress가 "subtitle" 사용자 정의 필드를 갖고 있었다고 해서 Sanity가 필요한 것은 아닙니다. 아마도 구조화된 "hero" 객체의 일부여야 할 수도 있습니다.
  2. 객체를 과도하게 중첩: Sanity는 깊게 객체를 중첩할 수 있습니다. 충동을 저항하세요. 평탄한 스키마는 GROQ로 쿼리하기 더 쉽고 편집자가 작업하기 더 쉽습니다.
  3. Portable Text의 힘 무시: HTML을 단일 텍스트 필드에 버리지 마세요. 콘텐츠 패턴과 일치하는 사용자 정의 블록 타입을 설계합니다. "callout" 블록, "code snippet" 블록, "image with caption" 블록 — 이들은 편집자의 생활을 더 낫게 만듭니다.

스키마 설계 프로세스

이 순서를 따릅니다:

  1. 기존 콘텐츠 감사 (사전 마이그레이션에서 완료)
  2. 실제 콘텐츠 패턴 식별 (CMS가 강요한 것이 아님)
  3. 종이/화이트보드에서 먼저 스키마 설계
  4. 코드에서 스키마 빌드
  5. 작은 테스트 배치 가져오기 (50-100개 항목)
  6. Studio 경험 테스트를 위해 편집자 갖기
  7. 전체 마이그레이션 전에 스키마에서 반복

단계 5-7은 중요하며 종종 건너뜁니다. 우리는 헤드리스 CMS 개발 작업에서 콘텐츠 모델링 접근 방식에 대해 더 많이 썼습니다.

데이터 마이그레이션 전략 및 도구

필수 도구

  • @sanity/client: Sanity 데이터를 읽고 쓰기 위한 공식 JavaScript 클라이언트
  • @sanity/block-tools: HTML을 Portable Text로 변환
  • sanity dataset import/export: 전체 데이터셋 작업을 위한 CLI 도구
  • ndjson: Sanity는 가져오기에 줄 구분 JSON을 사용합니다. 익숙해지세요.
  • jsdom 또는 htmlparser2: 리치 텍스트 변환 중 HTML 구문 분석

마이그레이션 아키텍처

모든 마이그레이션을 4단계 파이프라인으로 구조화합니다:

Extract → Transform → Load → Validate

각 단계는 별도의 스크립트입니다. 이것은 마이그레이션을 여러 번 실행하게 되기 때문에 중요합니다. 일반적으로 최종 프로덕션 실행 전에 5-10회입니다. 별도의 단계를 갖는 것은 수정이 필요한 부분만 다시 실행할 수 있다는 의미입니다.

# 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

자산 처리

이미지와 파일은 항상 가장 느린 부분입니다. Sanity의 자산 파이프라인은 좋지만 10,000개 이미지를 업로드하는 데 시간이 걸립니다. 팁:

  • 자산을 먼저 업로드하고, 이전 URL에서 새로운 Sanity 자산 ID로의 매핑을 유지합니다.
  • 동시 업로드를 사용합니다 (하지만 속도 제한을 존중합니다. Growth 플랜의 경우 초당 25개 요청).
  • 업로드 전에 이미지 치수 및 형식을 확인합니다.
  • 썸네일 크기를 마이그레이션하지 마세요. Sanity는 이미지 CDN을 통해 즉시 생성합니다.

아무도 말하지 않는 숨겨진 비용

마이그레이션 추정치에 나타나지 않는 비용에 대해 솔직하게 말하겠습니다.

URL 리다이렉트

프론트엔드를 변경하는 경우 (Sanity로 이동하는 경우 아마도 변경), URL 매핑 리다이렉트가 필요합니다. 모든 것이. SEO의 경우 불가피합니다. 5,000개 페이지가 있는 사이트는 5,000개 리다이렉트 규칙이 필요합니다. next.config.js 리다이렉트 또는 Vercel의 _redirects 파일과 같은 도구가 이를 처리할 수 있지만 누군가는 매핑을 구축해야 합니다.

SEO 메타데이터 마이그레이션

WordPress의 Yoast SEO 데이터. Drupal의 Metatag 모듈 데이터. Contentful의 SEO 필드. 이 모든 것을 가져와야 합니다. 사용자 정의 메타 제목, 설명, Open Graph 이미지, 정규 URL, 구조화된 데이터 — 프로젝트 내 프로젝트입니다.

편집자 교육 및 문서

최소 2-4일을 예산합니다. Sanity Studio는 직관적이지만 편집자가 알고 있는 것과 다릅니다. 일반적으로 스크린샷이 있는 사용자 정의 Studio 문서를 만들고 3-5개의 연습 비디오를 기록합니다.

프론트엔드 개발

이것이 방의 코끼리입니다. Sanity로 콘텐츠를 마이그레이션하는 것은 프로젝트의 절반일 뿐입니다. 또한 콘텐츠를 소비하는 프론트엔드가 필요합니다. Next.js, Astro 또는 다른 프레임워크를 사용하든 프론트엔드 빌드는 종종 총 프로젝트 비용의 50-70%입니다. 프론트엔드 옵션을 평가하는 경우 Next.js 및 Astro와의 작업을 확인합니다.

일정 및 예산 비교

2024-2025년에 완료한 프로젝트를 기반으로:

마이그레이션 경로 콘텐츠 볼륨 복잡성 일정 예산 범위
WordPress → Sanity < 1,000 페이지 낮음 3-5주 $8K-$15K
WordPress → Sanity 1,000-10,000 페이지 중간 6-10주 $15K-$35K
WordPress → Sanity 10,000+ 페이지 높음 10-16주 $35K-$75K
Contentful → Sanity < 5,000 항목 낮음-중간 3-5주 $7K-$18K
Contentful → Sanity 5,000-20,000 항목 중간 5-8주 $18K-$40K
Drupal → Sanity < 2,000 노드 중간 5-8주 $12K-$25K
Drupal → Sanity 2,000-15,000 노드 높음 8-14주 $25K-$60K
Drupal 7 → Sanity 모든 매우 높음 10-20주 $35K-$90K

참고: 이 범위에는 콘텐츠 마이그레이션만 포함됩니다. 프론트엔드 개발은 별도입니다. 프로젝트별 추정을 위해 /pricing에서 문의하세요.

이 숫자에는 콘텐츠 모델링, 마이그레이션 스크립팅, 데이터 검증 및 기본 편집자 교육이 포함됩니다. 프론트엔드 개발, 설계 또는 지속적인 유지 관리는 포함되지 않습니다.

마이그레이션 후 체크리스트

모든 마이그레이션에서 사용하는 체크리스트는 다음과 같습니다:

  • 모든 콘텐츠 타입 마이그레이션 및 검증됨
  • 모든 참조/관계 손상됨
  • 모든 이미지 및 파일 업로드되고 올바르게 연결됨
  • 리치 텍스트 콘텐츠가 올바르게 렌더링됨 (형식 손상 확인)
  • URL 리다이렉트 준비 및 테스트됨
  • SEO 메타데이터 마이그레이션됨 (제목, 설명, OG 데이터)
  • XML 사이트맵 재생성됨
  • 검색 콘솔이 새 사이트맵으로 업데이트됨
  • 분석 추적 보존됨
  • 편집자 계정 생성 및 권한 설정
  • 편집자 교육 완료됨
  • 콘텐츠 미리보기 (초안 모드) 작동
  • 빌드 트리거를 위한 Webhooks 구성됨
  • 소스 CMS 데이터 백업 보관됨
  • DNS 변경 계획 (적용 가능한 경우)
  • 성능 기준선 측정됨
  • 처음 30일 동안 404 모니터링 설정됨

마지막 포인트가 중요합니다. 리다이렉트 매핑이 얼마나 철저하든 일부 URL은 빠져나갈 것입니다. 처음 달 동안 404를 적극적으로 모니터링합니다.

FAQ

WordPress에서 Sanity로의 일반적인 마이그레이션은 얼마나 걸립니까?

표준 WordPress 사이트 (2,000개 미만의 포스트, 간단한 사용자 정의 필드)의 경우 4-8주를 예상합니다. 여기에는 콘텐츠 모델링, 마이그레이션 스크립팅, 데이터 검증 및 편집자 교육이 포함됩니다. 복잡한 Gutenberg 블록, WooCommerce 또는 다국어 콘텐츠가 있는 사이트는 10-16주가 걸릴 수 있습니다. 콘텐츠 볼륨은 콘텐츠 타입의 복잡성보다 덜 중요합니다.

Contentful에서 Sanity로 마이그레이션하면서 데이터를 잃을 수 있습니까?

예, 실제로 여기서 다루는 세 가지 중 가장 깔끔한 마이그레이션 경로입니다. 두 플랫폼 모두 구조화된, JSON 기반 콘텐츠를 사용하므로 매핑이 상대적으로 직접적입니다. 리치 텍스트는 Contentful 형식에서 Portable Text로 변환되어야 하고 참조는 다시 매핑되어야 하지만 데이터를 잃지 않아야 합니다. 전체 프로덕션 전에 스테이징 데이터셋에 대해 마이그레이션을 실행한 다음 철저한 콘텐츠 비교를 수행하는 것을 권장합니다.

CMS 마이그레이션 중 SEO 순위는 어떻게 됩니까?

마케팅 이사가 밤에 깨어있게 하는 질문입니다. 리다이렉트를 올바르게 처리하고 가능한 경우 URL 구조를 유지하며 모든 SEO 메타데이터를 마이그레이션하면 최소한의 영향을 볼 수 있습니다. Google의 자체 문서는 적절하게 리다이렉트된 마이그레이션이 복구 전에 2-4주의 임시 하락을 볼 수 있다고 말합니다. 핵심은 "적절하게"입니다. 리다이렉트 매핑을 건너뛰면 순위가 떨어집니다. 우리는 그것을 봤습니다.

Sanity가 엔터프라이즈 사용을 위해 Contentful보다 저렴합니까?

대부분의 경우 예입니다. 때로는 상당히. Sanity의 Growth 플랜은 월 $99로 Contentful의 월 $300 Team 플랜이 필요한 것을 커버합니다. 엔터프라이즈 규모에서 차이는 더 커집니다. Contentful의 Premium 가격은 공개되지 않지만 일반적으로 월 $2,000-$4,000 이상입니다. Sanity 엔터프라이즈 가격도 사용자 정의이지만 일반적으로 동등한 사용량에 대해 더 낮습니다. 실제 비용 차이는 API 호출에 있습니다. Sanity의 포함된 한도가 더 관대합니다.

Drupal 7 사이트를 Sanity로 마이그레이션하거나 먼저 Drupal 10으로 업그레이드해야 합니까?

Sanity로 직접 가세요. Drupal 7에서 Drupal 10으로의 마이그레이션은 다른 CMS로의 마이그레이션과 거의 같은 작업입니다. 버전 간에 아키텍처가 그토록 크게 변경되었습니다. 이미 주요 마이그레이션에 투자하고 있다면 장기적으로 실제로 원하는 플랫폼으로 이동하는 것이 좋습니다. 한 가지 예외: 팀이 Drupal 생태계에 깊숙이 투자되어 있고 단순히 현대화하려는 경우, 헤드리스 프론트엔드가 있는 Drupal 10은 유효한 경로입니다.

Sanity로 마이그레이션할 때 프론트엔드를 다시 구축해야 합니까?

WordPress 또는 Drupal과 같은 모놀리식 CMS에서 오는 경우, 예입니다. Sanity는 헤드리스이므로 새 프론트엔드가 필요합니다. 이것은 보통 프로젝트의 더 큰 부분입니다. Contentful에서 오는 경우, 특히 이미 Next.js 또는 유사한 프레임워크를 사용하는 경우 종종 기존 프론트엔드를 수정된 API 호출로 재사용할 수 있습니다. CMS 마이그레이션과 프론트엔드 빌드를 통합 프로젝트로 처리합니다.

Sanity 마이그레이션 중에 팀이 기존 CMS와 Sanity를 병렬로 실행할 수 있습니까?

절대적으로, 그리고 권장합니다. 초기 마이그레이션 후 2-4주 동안 두 시스템을 모두 실행합니다. 편집자는 기존 CMS에서 계속 작업할 수 있는 동안 Sanity의 데이터를 검증합니다. 마지막 마이그레이션 실행 48시간 전에 기존 시스템의 콘텐츠를 동결하세요. 이동하는 대상을 추격하고 싶지 않습니다. 일부 팀은 최종 전환 48시간 전에 "콘텐츠 동결" 날짜를 설정합니다.

팀이 Sanity 마이그레이션 중에 저지르는 가장 큰 실수는 무엇입니까?

기존 CMS 구조를 Sanity에서 정확히 복제하려고 시도합니다. 이것은 항상 봅니다. 팀은 WordPress에서 오고 Sanity에서 WordPress 모양의 스키마를 구축하려고 시도합니다. 유연한 레이아웃 대신 목적에 맞춘 콘텐츠 타입을 사용하는 일반적인 "페이지" 타입입니다. Sanity의 장점은 구조화된 콘텐츠입니다. 마이그레이션을 콘텐츠를 올바르게 모델링할 기회로 사용합니다. 콘텐츠 모델링에 추가 주를 보내세요. 나중에 몇 개월를 절약할 수 있습니다. 이에 대한 지침이 필요한 경우 문의하세요. 콘텐츠 모델링은 마이그레이션 프로젝트에서 가장 많은 시간을 소비하는 것 중 하나입니다.