دليل هجرة Sanity: الخروج من WordPress و Contentful و Drupal
يوافق فريقك على الانتقال إلى Sanity. تصدر 80,000 منشور من WordPress، وتشغّل نسخة Studio، وتكتشف أن نصف حقول البيانات الوصفية تتبع ثلاثة مخططات مختلفة — ولا أحد وثّق منطق التصنيفات المخصصة الذي يدعم ملاحة موقعك بالكامل. لقد أجريت أكثر من 40 هجرة إلى Sanity على مدى ثلاث سنوات. اكتملت بعضها في أسبوعين. امتدت أخرى إلى ثلاثة أشهر وجعلتني أعيد التفكير في كل قرار قادني إلى العمل الحر. لم يكن الفرق مطلقاً بخصوص ما إذا كنت تغادر WordPress أو Contentful أو Drupal. لقد تعلق الأمر بثلاثة أشياء: مدى صراحتك في تحديد نطاق نموذج المحتوى مقدماً، وما إذا تعاملت مع رسم الخرائط بين الحقول كمعمارية أم عمل روتيني، وما إذا اعترف أحد من فريقك بأنه لا يفهم كيف يعمل نظام إدارة المحتوى القديم الخاص بك فعلياً. يرشدك هذا الدليل خلال كل قرار يحدد ما إذا كانت هجرتك هي سباق نظيف أم تفكك بطيء الحركة — ويعرض عليك قوائم التحقق والنصوص البرمجية والنماذج الذهنية بالضبط التي تفصل بين الاثنين.
هذا هو الدليل الذي كنت أتمنى أن أملكه عندما بدأت في إجراء هجرات نظام إدارة المحتوى. يغطي الانتقال من WordPress و Contentful و Drupal إلى عالم Sanity الذي يدعم GROQ. سأكون صريحاً بشأن المجالات التي يتفوق فيها Sanity، والأماكن التي ستحبطك، وما تبدو عليه المخططات الزمنية الحقيقية.
جدول المحتويات
- لماذا تنتقل الفرق إلى Sanity في 2026
- تدقيق ما قبل الهجرة: الخطوة التي يتخطاها الجميع
- هجرة WordPress إلى Sanity
- هجرة Contentful إلى Sanity
- هجرة Drupal إلى Sanity
- نمذجة المحتوى: إصلاح المخططات الخاصة بك
- استراتيجيات ونقل البيانات والأدوات
- التكاليف المخفية التي لا يتحدث عنها أحد
- قائمة التحقق من بعد الهجرة
- مقارنة المخطط الزمني والميزانية
- الأسئلة الشائعة

لماذا تنتقل الفرق إلى Sanity في 2026
دعنا نتخلص من الأشياء الواضحة. التحرير التعاوني في الوقت الفعلي في Sanity، واستوديو قابل للتخصيص، ونهج المحتوى المنظم جيدة حقاً. لكن السبب الذي يجعل معظم الفرق تتواصل معنا بشأن الهجرة ليس لأنهم قراءوا منشور مدونة عن ميزات Sanity. إنه لأن شيئاً ما انقطع.
مواقع WordPress تصطدم بجدران التوسع حول 50,000+ قطعة محتوى مع أنواع منشورات مخصصة معقدة. نموذج تسعير Contentful يبدأ في الضغط على المستوى المؤسسي — رأينا فرق تواجه فواتير $3,500+/شهر مقابل ما يعادل واجهة برمجة تطبيقات محتوى. فرق Drupal لا تستطيع العثور على مطورين بعد الآن، على الأقل ليس من يريدون العمل مع قالب PHP في 2026.
نموذج تسعير Sanity أكثر توقعاً بشكل حقيقي لمعظم الفرق. تغطي الطبقة المجانية حتى 100 ألف طلب API/شهر و500 ألف أصل. تحصل خطة النمو بقيمة $99/شهر/مشروع على 2.5 مليون طلب API و1 مليون أصل. للمقارنة، تكلف خطة Team في Contentful $300/شهر وقد تتجاوز طبقة Contentful Premium بسهولة $2,000/شهر.
لكن هذا رأيي الصريح: إذا كان نظام إدارة المحتوى الحالي يعمل بشكل جيد والفريق منتج، فلا تهاجر فقط لأن Sanity أحدث أو أكثر برودة. الهجرات تكلف دائماً أكثر مما تعتقد.
تدقيق ما قبل الهجرة: الخطوة التي يتخطاها الجميع
قبل أن تكتب سطر واحد من كود الهجرة، تحتاج إلى تدقيق المحتوى. ليس فحص سريع — تدقيق فعلي. إليك ما يبدو عليه:
جرد المحتوى
وثّق كل نوع محتوى، كل حقل، كل علاقة. أستخدم جدول بيانات مع هذه الأعمدة:
- اسم نوع المحتوى
- إجمالي العناصر
- الحقول (مع الأنواع)
- العلاقات مع أنواع محتوى أخرى
- المرفقات الإعلامية (العدد والحجم الإجمالي)
- الوظائف المخصصة (الاختصارات، الأدوات، التضمينات)
- آخر تاريخ تم تعديله
- لا تزال ذات صلة؟ (نعم/لا/ربما)
ستندهش من كمية المحتوى الثقيل الميت. في هجرة WordPress واحدة، كان لدى العميل 12,000 منشور. بعد التدقيق، كان هناك فقط 4,200 منشور ذي صلة بالفعل. هذا 65٪ أقل محتوى للهجرة والاختبار والتحقق.
رسم خريطة الاعتماديات التقنية
درّج كل مكون إضافي أو وحدة أو تكامل يستخدمه نظام إدارة المحتوى الحالي. لكل واحد، حدد:
- هل يمكن لـ Sanity التعامل مع هذا بشكل أصلي؟
- هل هناك مكون إضافي Sanity له؟
- هل نحتاج إلى بناء حل مخصص؟
- هل يمكننا حذف هذا بالكامل؟
هذا الرسم بمفرده سيوفر عليك أسابيع من المفاجآت في الطريق.
تقييم جاهزية الفريق
Sanity Studio قائم على React. محررو المحتوى سيحتاجون إلى تدريب. سيحتاج المطورون إلى تعلم GROQ (أو استخدام GraphQL، على الرغم من أن GROQ هو حيث يتألق Sanity بحقاً). ميزانية 1-2 أسبوع للتدريب العملي للفريق — ليس كشيء جميل الوجود، بل كعنصر سطري.
هجرة WordPress إلى Sanity
WordPress هو أكثر مصدر CMS شيوعاً ننقل منه. إنه أيضاً الأصعب، لأن WordPress ليس مجرد CMS — إنه منصة تطبيق كاملة ألحق الناس بها كل شيء.
ما ينقل بنظافة
- المنشورات والصفحات (المحتوى الأساسي)
- الفئات والوسوم
- الصور المميزة
- بيانات المؤلف
- الحقول المخصصة الأساسية (ACF، Meta Box)
ما يصبح فوضوياً
- كتل Gutenberg: كل نوع كتلة يحتاج إلى كتلة Portable Text مخصصة أو نوع كائن Sanity المقابل. إذا كان لديك 15+ كتلة Gutenberg مخصصة، ميزانية وقت كبير هنا.
- الاختصارات: يجب تحليلها وتفسيرها وتحويلها إلى تعليقات توضيحية Portable Text أو أنواع كتل مخصصة. اختصارات WPBakery و Elementor مؤلمة بشكل خاص.
- محتوى منتج المكون الإضافي: منتجات WooCommerce، بيانات Yoast SEO، حقول معيد ACF — يحتاج كل واحد إلى منطق هجرة مخصص.
- مكتبة الوسائط: يخزن WordPress أحجام صور متعددة. يتعامل Sanity مع تحويلات الصور على الفور، لذلك تحتاج فقط إلى الأصول. لكن العثور على الأصول في مجلد wp-uploads فوضوي؟ أوقات ممتعة.
نهج النص البرمجي للهجرة
عادة ما أستخدم نص برمجي Node.js يضرب REST API لـ WordPress ويكتب إلى API الطفرات في 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)
}
}
دالة convertToPortableText هي حيث تعيش 80٪ من التعقيد. أستخدم حزمة @sanity/block-tools مع jsdom لتحليل HTML. يتعامل مع HTML الأساسي بشكل جيد، لكن العناصر والاختصارات المخصصة تحتاج إلى معالجات فردية.
الخط الزمني الواقعي
لموقع WordPress نموذجي يضم 500-2,000 منشور، حقول مخصصة قياسية، وحفنة من أنواع المنشورات المخصصة: 4-8 أسابيع تشمل نمذجة المحتوى، نص هجرة، التحقق من البيانات، وتدريب المحررين.

هجرة Contentful إلى Sanity
هجرة Contentful إلى Sanity هي فعلاً أنعم مسار هجرة من بين الثلاثة. لماذا؟ لأن كلاهما منصات محتوى منظمة مع نماذج ذهنية متشابهة. محتواك موجود بالفعل في CMS بدون رأس مع أنواع محتوى وحقول محددة.
الاختلافات الرئيسية التي يجب مراعاتها
| الميزة | Contentful | Sanity |
|---|---|---|
| النص الغني | Rich Text (قائم على JSON) | Portable Text (قائم على JSON) |
| نمذجة المحتوى | واجهة ويب | مخططات محددة في الكود |
| لغة الاستعلام | GraphQL / REST | GROQ (+ GraphQL) |
| التوطين | مدمج على مستوى الحقل | مكون إضافي أو مخصص |
| المراجع | الروابط (Entry/Asset) | مراجع مع الأنواع |
| الخطافات | نعم | نعم |
| معالجة الأصول | CDN مدمج | Sanity CDN + hotspot/crop |
| التسعير (منتصف المستوى) | ~$300/شهر (Team) | $99/شهر (Growth) |
تحويل النص الغني
Rich Text في Contentful و Portable Text في Sanity قائم على 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)، وليس في واجهة ويب. هذا هو في الواقع ميزة ضخمة — نموذج المحتوى الخاص بك يعيش في التحكم في الإصدار.
استخدم Contentful Management API لتصدير نموذج المحتوى الخاص بك، ثم اكتب نص برمجي ينشئ ملفات مخطط Sanity:
contentful space export --space-id YOUR_SPACE_ID --export-dir ./export
الخط الزمني الواقعي
لمساحة Contentful مع 10-20 نوع محتوى و5,000-10,000 إدخال: 3-5 أسابيع. إنه أسرع لأنك تفكر بالفعل في محتوى منظم.
هجرة Drupal إلى Sanity
هجرات Drupal هي التي تجعلني أصب فنجان قهوة ثاني. ليس لأن Drupal سيئ — إنه نظام قوي. لكن مواقع Drupal تميل إلى أن تكون قديمة، ومخصصة لأقصى حد، وتعمل على بنية تحتية لا أحد يفهمها بالكامل بعد الآن.
التحديات المحددة لـ Drupal
- أنواع محتوى مع 50+ حقل: يجعل Drupal من السهل إضافة الحقول. سهل جداً. رأيت أنواع محتوى بـ 80 حقل، نصفها غير مستخدم.
- مراجع شروط التصنيف: نظام الأصنومي في Drupal مرن ولكن يمكن أن ينشئ تسلسلات هرمية عميقة تحتاج إلى تسطيح لـ Sanity.
- وحدة الفقرات: إذا كان الموقع يستخدم Drupal Paragraphs (ومعظم مواقع Drupal الحديثة تفعل ذلك)، فإن كل نوع فقرة يصبح نوع كتلة Portable Text أو نوع كائن Sanity. هذه هي أكبر مهمة واحدة.
- كيانات الوسائط: نظام الوسائط في Drupal 9/10 أكثر تعقيداً من WordPress. أنواع وسائط متعددة، كيانات وسائط قابلة لإعادة الاستخدام، وتكوينات حقول الملفات كلها تحتاج إلى رسم الخرائط.
- المحتوى متعدد اللغات: نظام الترجمة في Drupal متطور. Sanity ليس لديه توطين مدمج على نفس المستوى — ستحتاج إلى مكون
@sanity/document-internationalizationأو نهج على مستوى الحقل.
نهج الهجرة
أفضل استخدام وحدة JSON:API في Drupal (مضمنة في Drupal core منذ 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()
}
لمواقع Drupal 7 الأقدم بدون JSON:API، قد تحتاج إلى الاستعلام عن قاعدة البيانات مباشرة. مخطط قاعدة بيانات Drupal 7 هو... تجربة. جداول field_data_* ستطارد أحلامك.
الخط الزمني الواقعي
هجرات Drupal تختلف اختلافاً كبيراً. موقع Drupal 10 مباشر مع 5-10 أنواع محتوى: 5-8 أسابيع. موقع Drupal 7 وراثي مع 30+ نوع محتوى، الفقرات، والمحتوى متعدد اللغات: 8-16 أسبوع. لا أبالغ.
نمذجة المحتوى: إصلاح المخططات الخاصة بك
هنا الشيء الذي لن تخبرك به معظم أدلة الهجرة: لا تكرر نموذج المحتوى القديم الخاص بك في Sanity. هذه فرصتك لإصلاح سنوات من تراكم ديون المحتوى.
أخطاء نمذجة شائعة
- إنشاء رسم خريطة حقل 1:1: فقط لأن WordPress كان يحتوي على حقل مخصص "subtitle" لا يعني أن Sanity يحتاج إلى واحد. ربما يجب أن تكون جزءاً من كائن "hero" منظم.
- الإفراط في دمج الكائنات: يتيح Sanity لك دمج الكائنات بعمق. قاوم الرغبة. المخططات المسطحة نسبياً أسهل في الاستعلام مع GROQ وأسهل في العمل بها للمحررين.
- تجاهل قوة Portable Text: لا تصب HTML في حقل نص واحد فقط. صمّم أنواع كتل مخصصة تطابق أنماط المحتوى الخاصة بك. كتلة "callout"، كتلة "code snippet"، كتلة "image with caption" — هذه تجعل حياة المحررين أفضل.
عملية تصميم المخطط
أتبع هذا الترتيب:
- تدقيق المحتوى الموجود (مكتمل في قبل الهجرة)
- حدد أنماط المحتوى الفعلية (وليس ما فرضه نظام إدارة المحتوى)
- صمّم المخططات على الورق/السبورة البيضاء أولاً
- بناء المخططات في الكود
- استيراد دفعة اختبار صغيرة (50-100 عنصر)
- اجعل المحررين يختبرون تجربة Studio
- كرّر على المخططات قبل الهجرة الكاملة
الخطوات 5-7 حرجة وغالباً ما يتم تخطيها. لقد كتبنا المزيد عن نماذج نمذجة المحتوى في عمل تطوير CMS بدون رأس الخاص بنا.
استراتيجيات ونقل البيانات والأدوات
الأدوات الأساسية
@sanity/client: عميل JavaScript الرسمي للقراءة/الكتابة إلى بيانات Sanity@sanity/block-tools: تحويل HTML إلى Portable Textsanity dataset import/export: أدوات CLI لعمليات مجموعة البيانات الكاملةndjson: يستخدم Sanity JSON محدود بسطر جديد للواردات — اعتد بهjsdomأوhtmlparser2: لتحليل HTML أثناء تحويل النص الغني
معمارية الهجرة
أنظم كل هجرة كمسار مع أربع مراحل:
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 الجديدة
- استخدام تحميلات متزامنة (لكن احترم حدود معدل — 25 طلب/ثانية لخطة النمو)
- التحقق من أبعاد وتنسيقات الصور قبل التحميل
- لا تهاجر أحجام الصور المصغرة — Sanity ينتج هذه على الفور عبر CDN الصور الخاص بها
التكاليف المخفية التي لا يتحدث عنها أحد
دعني أكون صريحاً معك حول التكاليف التي لا تظهر في تقدير الهجرة النموذجي.
إعادة التوجيه من عناوين URL
إذا كنت تغيير واجهتك (وهذا ما تفعله احتمال إذا كنت تنتقل إلى CMS بدون رأس)، فأنت بحاجة إلى رسم خريطة إعادة التوجيه. كل. عنوان. URL. واحد. بالنسبة لـ SEO، هذا غير قابل للتفاوض. موقع بـ 5,000 صفحة يحتاج إلى 5,000 قاعدة إعادة توجيه. الأدوات مثل إعادة توجيه next.config.js أو ملف _redirects الخاص بـ Vercel يمكنها التعامل مع هذا، لكن يجب على شخص ما بناء التعيين.
هجرة بيانات تعريف SEO
بيانات Yoast SEO من WordPress. بيانات وحدة Metatag من Drupal. حقول Contentful SEO. كل هذا يحتاج إلى المجيء. عناوين ووصفات البيانات الوصفية المخصصة، صور Open Graph، عناوين URL البريدية، البيانات المنظمة — إنها مشروع داخل المشروع.
تدريب المحررين والتوثيق
ميزانية 2-4 أيام على الأقل. Sanity Studio حدسي، لكنه مختلف عما يعرفه المحررون. عادة ما ننشئ توثيق Studio مخصص مع لقطات شاشة ونسجل 3-5 مقاطع فيديو شرح.
تطوير الواجهة الأمامية
هذا هو الفيل في الغرفة. نقل المحتوى إلى Sanity هو نصف المشروع فقط. تحتاج أيضاً إلى واجهة أمامية تستهلك المحتوى. سواء كنت تستخدم Next.js أو Astro أو إطار عمل آخر، فإن بناء الواجهة الأمامية غالباً ما يكون 50-70٪ من تكلفة المشروع الإجمالية. تحقق من عملنا مع Next.js و Astro إذا كنت تقيّم خيارات الواجهة الأمامية.
مقارنة المخطط الزمني والميزانية
بناءً على المشاريع التي أكملناها في السنوات الأخيرة:
| مسار الهجرة | حجم المحتوى | التعقيد | المخطط الزمني | نطاق الميزانية |
|---|---|---|---|---|
| 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 المعاد إنشاؤها
- وحدة تحكم البحث محدثة مع خريطة الموقع الجديدة
- تتبع التحليلات المحفوظ
- حسابات المحررين التي تم إنشاؤها ومجموعات الأذونات
- اكتمل التدريب المحرر
- معاينة المحتوى (وضع المسودة) يعمل
- تم تكوين الخطافات لتشغيل المحلل
- تم أرشفة نسخة احتياطية من بيانات نظام إدارة المحتوى المصدر
- تم التخطيط لتغييرات DNS (إن أمكن)
- تم قياس أساس الأداء
- تم تعيين مراقبة 404 لأول 30 يوماً
النقطة الأخيرة مهمة. بغض النظر عن مدى شمولية رسم خريطة إعادة التوجيه الخاص بك، ستتسلل بعض عناوين URL. راقب أخطاء 404 الخاصة بك بقوة للشهر الأول.
الأسئلة الشائعة
كم من الوقت تستغرق هجرة WordPress إلى Sanity نموذجية؟ لموقع WordPress قياسي يضم أقل من 2,000 منشور وحقول مخصصة مباشرة، توقع 4-8 أسابيع. يتضمن ذلك نمذجة المحتوى، نص الهجرة، التحقق من البيانات، وتدريب المحررين. يمكن لمواقع بها كتل Gutenberg معقدة أو WooCommerce أو محتوى متعدد اللغات أن تستغرق 10-16 أسبوع. حجم المحتوى أقل أهمية من تعقيد أنواع المحتوى الخاصة بك.
هل يمكنني الهجرة من Contentful إلى Sanity بدون فقدان البيانات؟ نعم، إنه فعلاً أنعم مسار هجرة من بين الثلاثة التي أغطيها هنا. تستخدم كلا المنصتين محتوى منظم قائم على JSON بحيث يكون التعيين مباشر نسبياً. يحتاج النص الغني إلى التحويل من تنسيق Contentful إلى Portable Text، وتحتاج المراجع إلى إعادة رسم الخرائط، لكنك لا يجب أن تفقد أي بيانات. أوصي بتشغيل الهجرة مقابل مجموعة بيانات التسوية أولاً وإجراء مقارنة محتوى شاملة قبل الانتقال.
ماذا يحدث لتصنيفات SEO الخاصة بي أثناء هجرة نظام إدارة المحتوى؟ هذا هو السؤال الذي يبقي مديري التسويق مستيقظين في الليل. إذا تعاملت مع إعادات التوجيه بشكل صحيح، والحفاظ على بنية عنوان URL حيث أمكن، والهجرة جميع بيانات تعريف SEO، يجب أن تشهد تأثير ضئيل. توثيق Google نفسه يقول أن الهجرات التي تم إعادة توجيهها بشكل صحيح قد ترى انخفاض مؤقت من 2-4 أسابيع قبل التعافي. الكلمة الرئيسية هي "بشكل صحيح". تخطي رسم خريطة إعادة التوجيه وستنسف التصنيفات الخاصة بك. رأينا ذلك يحدث.
هل Sanity أرخص من Contentful للاستخدام المؤسسي؟ في معظم الحالات، نعم — أحياناً بشكل كبير. خطة Growth في Sanity بقيمة $99/شهر تغطي ما تحتاج Contentful's $300/شهر Team plan له. في نطاق المؤسسة، يصبح الفرق أكبر. لا يتم نشر تسعير Contentful Premium علناً لكن عادة ما يتراوح بين $2,000-$4,000+/شهر. يتم تخصيص تسعير Sanity Enterprise أيضاً ولكنه بشكل عام يكون أقل للاستخدام المعادل. الفرق الحقيقي في التكلفة موجود في طلبات API — الحدود المضمنة في Sanity أكثر سخاء.
هل يجب أن أهاجر موقع Drupal 7 الخاص بي إلى Sanity أم ترقية إلى Drupal 10 أولاً؟ اذهب مباشرة إلى Sanity. الهجرة من Drupal 7 إلى Drupal 10 تقريباً بقدر العمل كالهجرة إلى CMS مختلف تماماً — تغيرت المعمارية بهذا الشكل بين الإصدارات. إذا كنت تستثمر بالفعل في هجرة كبرى، فقد تكون بنفس القدر تنتقل إلى المنصة التي تريد أن تكون عليها على المدى الطويل. الاستثناء الوحيد: إذا كان فريقك مستثمر بعمق في نظام Drupal البيئي وفقط يريد التحديث، فإن Drupal 10 مع واجهة أمامية بدون رأس هو مسار صحيح.
هل أحتاج إلى إعادة بناء واجهتي الأمامية عند الهجرة إلى Sanity؟ إذا كنت قادماً من CMS أحادي اللون مثل WordPress أو Drupal، نعم — ستحتاج إلى واجهة أمامية جديدة لأن Sanity بدون رأس. هذا عادة ما يكون الجزء الأكبر من المشروع. إذا كنت قادماً من Contentful، يمكنك غالباً إعادة استخدام الواجهة الأمامية الموجودة مع استدعاءات API المعدلة، خاصة إذا كنت تستخدم Next.js أو إطار عمل مشابه بالفعل. نتعامل مع هجرة نظام إدارة المحتوى وبناء الواجهة الأمامية كمشاريع متكاملة.
هل يمكن تشغيل نظام إدارة المحتوى القديم والجديد Sanity بالتوازي أثناء الهجرة؟ بالتأكيد، وأوصي به. قم بتشغيل كلا النظامين لمدة 2-4 أسابيع بعد الهجرة الأولية. يمكن للمحررين الاستمرار في العمل في نظام إدارة المحتوى القديم بينما تتحقق من البيانات في Sanity. فقط تجميد المحتوى في النظام القديم قبل آخر تشغيل للهجرة — لا تريد مطاردة هدف متحرك. قد يعين بعض الفريق "تجميد محتوى" قبل 48 ساعة من الانتقال النهائي.
ما أكبر خطأ تقوم به الفرق أثناء هجرة Sanity؟ محاولة تكرار بنية نظام إدارة المحتوى القديم بالضبط في Sanity. أرى هذا باستمرار. تأتي الفرق من WordPress وتحاول بناء مخططات بشكل WordPress في Sanity — أنواع "صفحة" عامة مع تخطيطات مرنة بدلاً من أنواع محتوى مخصصة مبنية للغرض. قوة Sanity هي محتوى منظم. استخدم الهجرة كفرصة لنمذجة المحتوى بشكل صحيح. اقضِ أسبوع إضافي في نمذجة المحتوى. سيوفر عليك أشهر من الألم بعد ذلك. إذا كنت تريد التوجيه على هذا، تواصل معنا — نمذجة المحتوى هي أحد الأشياء التي نقضي أكثر وقت عليها في مشاريع الهجرة.