موقع الإنتاج الخاص بك يعمل على Drupal 7، واعتباراً من 5 يناير 2025، توقف عن تلقي تحديثات الأمان. لا إصلاحات طارئة. لا دعم من المجتمع. لا مزيد من الإضافات. لقد قادت ستة فريق من الفريق الإنتاجي عبر هذا الترحيل في الثمانية عشر شهراً الماضية، والنمط واضح: أولئك الذين تعاملوا معها مثل صندوق Q4 دفعوا 40-60% أكثر من أولئك الذين خططوا قبل ستة أشهر. ضريبة التأخير حقيقية — ليس فقط من حيث الدولار، بل في الديون التقنية التي يرثها مهندسوك عندما يضطرون إلى شحن الترحيل في ثمانية أسابيع بدلاً من عشرين. هذا هو الدليل الذي أعطيه لكل VP of Engineering في اللحظة التي يعترفون فيها بأن Drupal 7 لا يزال يدعم ممتلكاتهم الرئيسية. أنت لست متأخراً بعد، لكن النافذة تغلق بسرعة أكبر مما يعترف به جدول الأعمال الخاص بك.

جدول المحتويات

Drupal 7 End of Life 2025: Migration Guide for Enterprise Teams

ماذا يعني انتهاء دعم Drupal 7 فعلياً

دعنا نكون دقيقين حول ما يعنيه "انتهاء الحياة" من الناحية العملية، لأنني رأيت الكثير من الالتباس هنا:

  • لا مزيد من تحديثات الأمان. فريق أمان Drupal لن يصدر استشارات أو تصحيحات لـ Drupal 7 core أو وحدات contrib. إذا تم اكتشاف ثغرة حقن SQL حرجة غداً، فأنت وحدك.
  • لا مزيد من إصلاحات الأخطاء. أي شيء معطل يبقى معطلاً.
  • مشرفو وحدات Contrib ينتقلون. معظمهم بالفعل. لم ترَ العديد من وحدات Drupal 7 الشهيرة تحديثاً منذ سنوات.
  • مزودو الاستضافة سيسقطون الدعم. أعلنت Pantheon و Acquia و Platform.sh جميعاً جداول زمنية لإيقاف بيئات استضافة Drupal 7. مدد Acquia دعم Drupal 7 الخاص بهم حتى عام 2026 للعملاء الحاليين، لكن هذا إضافة مدفوعة، وليس حلاً طويل الأجل.
  • مشاكل توافق PHP ستتفاقم. تم بناء Drupal 7 لـ PHP 5.x. يعمل على PHP 8.1 مع التصحيحات، لكن PHP 8.1 نفسه يصل إلى نهاية حياته في ديسمبر 2025. ستكون بصدد تكديس البرامج غير المدعومة فوق البرامج غير المدعومة.

مخاطر الأمان وحدها يجب أن تكون كافية لتحفيز الإجراء. إذا كانت منظمتك تتعامل مع أي شكل من أشكال PII أو البيانات المالية أو معلومات الصحة، فإن تشغيل Drupal 7 غير المصحح هو مسؤولية الامتثال. PCI DSS و HIPAA و SOC 2 — جميعها تتطلب الاحتفاظ بالبرامج المصححة والمدعومة.

لماذا استمرت فرق الإنتاج في التأخير

لقد أجريت هذه المحادثة عشرات المرات. الأسباب دائماً نوع من:

  1. "موقع Drupal 7 الخاص بنا يعمل بشكل جيد." إنه كذلك. حتى لا يحدث ذلك. لن يتوقف الكود عن العمل في السادس من يناير، لكن ملف تعريف المخاطر يتغير بشكل كبير.
  2. "الترحيل من Drupal 8/9/10 ليس ترقية بسيطة." هذا صحيح فعلاً. بخلاف مسار الترقية من Drupal 6 إلى 7، فإن الانتقال من Drupal 7 إلى Drupal الحديث هو في الأساس إعادة بناء. الهندسة المعمارية مختلفة بشكل أساسي — مستندة إلى Symfony وإدارة التكوين وقوالب Twig. وحداتك المخصصة لن تنقل.
  3. "لدينا 15 سنة من المحتوى والوظائف المخصصة." مواقع Drupal 7 الإنتاجية تميل إلى أن تكون مخصصة بشدة. وحدات مخصصة وتكوينات Views معقدة وهياكل taxonomy معقدة وتكاملات مع الأنظمة القديمة. نطاق الترحيل كبير حقاً.
  4. "لم يتم الموافقة على الميزانية." الإجابة الأكثر صراحة، والأكثر شيوعاً.

لم يختفِ أي من هذه الأسباب، لكن الموعد النهائي وصل فعلاً. فلنتحدث عن ما يجب فعله فعلاً.

خيارات الترحيل الخاصة بك في 2026

لديك أربع مسارات واقعية للمضي قدماً. لكل منها مقايضات. دعني أكسرها بصراحة.

الخيار الجدول الزمني نطاق التكلفة الأفضل ل مستوى المخاطرة
Drupal 10/11 6-18 شهراً $200K-$1M+ الفرق المستثمرة في نظام Drupal البيئي متوسط
واجهة أمامية بدون رؤوس + خادم Drupal 4-12 شهراً $150K-$600K الفرق التي تريد UX حديث مع CMS مألوف متوسط
ترحيل Headless CMS 3-9 أشهر $100K-$500K الفرق المستعدة للترك من Drupal تماماً متوسط-مرتفع
مزود الدعم الموسع فوري $30K-$100K/سنة الفرق التي تحتاج 6-18 شهراً إضافياً لوقت التخطيط منخفض (قصير الأجل)

Drupal 7 End of Life 2025: Migration Guide for Enterprise Teams - architecture

الخيار 1: الترحيل إلى Drupal 10/11

Drupal 10 هو إصدار مستقر حالي اعتباراً من 2026، حيث تم إطلاق Drupal 11 في منتصف عام 2024 واكتسب اعتماداً قوياً. إذا كان فريقك يعرف Drupal وكان نموذج المحتوى الخاص بك سليماً وكنت تريد البقاء في النظام البيئي، فهذا هو المسار الأكثر وضوحاً.

لكن "مباشر" لا يعني "سهل".

ما يتضمنه الترحيل فعلياً

يوفر Drupal Migrate API الذي يمكنه سحب المحتوى من قاعدة بيانات Drupal 7 إلى موقع Drupal 10/11. في تجربتي، يتعامل مع حوالي 60-70% من الترحيل النموذجي. الباقي هو plugins ترحيل مخصص ل:

  • أنواع حقول مخصصة
  • مراجع الكيانات المعقدة
  • الفقرات (إذا استخدمت وحدة Paragraphs)
  • أصول الملفات والوسائط
  • اسم مستعار URL والتحويلات
  • حسابات المستخدمين والأدوار

تحتاج وحداتك المخصصة إلى إعادة كتابة. ليس نقل — إعادة كتابة. يستخدم Drupal 10/11 هندسة معمارية مختلفة تماماً. إذا كان لديك وحدة مخصصة تربط إلى hook_node_view(), فأنت الآن تكتب مشتركي أحداث وplugins.

// Drupal 7 - hook-based
function mymodule_node_view($node, $view_mode, $langcode) {
  if ($node->type == 'article') {
    $node->content['custom_field'] = array(
      '#markup' => '<div>' . custom_logic($node) . '</div>',
      '#weight' => 10,
    );
  }
}

// Drupal 10/11 - OOP, Symfony-based
namespace Drupal\mymodule\EventSubscriber;

use Drupal\core_event\NodeViewEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

class NodeViewSubscriber implements EventSubscriberInterface {
  public static function getSubscribedEvents() {
    return [NodeViewEvent::class => 'onNodeView'];
  }
  
  public function onNodeView(NodeViewEvent $event) {
    $node = $event->getNode();
    if ($node->bundle() === 'article') {
      // Your logic here
    }
  }
}

طبقة Twig الخاصة بالنماذج أيضاً مختلفة تماماً عن PHPTemplate. يجب إعادة بناء كل سمة مخصصة.

جدول زمني واقعي

بالنسبة لموقع متوسط الحجم من الشركات (500-5,000 صفحة، 10-20 نوع محتوى، 5-10 وحدات مخصصة)، توقع 9-15 شهراً. يتضمن ذلك الاكتشاف وتصميم المحتوى والتطوير والترحيل والاختبار والإطلاق.

الخيار 2: الانتقال إلى Headless مع واجهة أمامية حديثة

هنا حيث تصبح الأمور مثيرة للاهتمام، وبصراحة، إنه النهج الذي أوصي به في أغلب الأحيان لفرق الشركات في 2026. احتفظ بـ Drupal كخادم محتوى (مع الترقية إلى Drupal 10/11)، لكن بناء الواجهة الأمامية مع إطار عمل JavaScript حديث.

Drupal 10/11 لديه دعم JSON:API ممتاز مدمج في النواة. يمكنك تعريض محتواك كبيانات منظمة والاستهلاك باستخدام Next.js أو Astro أو أي إطار عمل واجهة أمامية.

لماذا يعمل هذا النهج بشكل جيد

  • فريق المحررين الخاص بك يحتفظ بواجهة إدارة Drupal. إنهم يعرفونها. هم منتجون فيها. إزالة هذا تسبب ألم تنظيمي.
  • الواجهة الأمامية الخاصة بك تصبح أسرع بشكل كبير. الإنشاء الثابت وتخزين الحواف المؤقت وتحسين الصور الحديثة — أشياء مؤلمة لإضافتها إلى طبقة الرندر الخاصة بـ Drupal.
  • يمكنك الترحيل تدريجياً. قم بإنشاء الواجهة الأمامية الجديدة إلى جانب الموقع القديم وترحيل الأقسام واحداً تلو الآخر.

لقد بنينا عدة واجهات أمامية بدون رؤوس مع Next.js و Astro، وتحسينات الأداء كبيرة. رأى أحد العملاء أن أكبر رسم محتوى انخفض من 4.2 ثانية إلى 0.8 ثانية بعد الانتقال إلى واجهة أمامية مع ISR (Incremental Static Regeneration).

// Next.js page fetching from Drupal's JSON:API
export async function getStaticProps({ params }) {
  const res = await fetch(
    `${process.env.DRUPAL_BASE_URL}/jsonapi/node/article?filter[field_slug]=${params.slug}&include=field_image,field_tags`
  );
  const data = await res.json();
  
  return {
    props: {
      article: data.data[0],
      included: data.included,
    },
    revalidate: 60, // ISR: regenerate every 60 seconds
  };
}

تجعل حزمة next-drupal (التي تحتفظ بها Chapter Three) هذا أسهل مع الدعم المدمج لوضع المعاينة والمصادقة وتعيين نوع المحتوى.

المشكلة

تحتاج إلى الترحيل من Drupal 7 إلى Drupal 10/11 في الخلفية. أنت لا تتجنب هذا العمل. لكنك تفصل عن إعادة بناء الواجهة الأمامية، مما يعطيك مرونة أكبر في تسلسل العمليات.

الخيار 3: الانتقال إلى Headless CMS بالكامل

أحياناً يكون الخيار الصحيح ترك Drupal تماماً. إذا كان فريقك لا يملك خبرة قوية بـ Drupal، إذا كنت تعاني من صعوبة تعيين مطوري Drupal (وأنت تفعل ذلك — تقلصت قاعدة موهبة Drupal بشكل كبير منذ 2020)، أو إذا كان نموذج المحتوى الخاص بك قد تجاوز ما يفعله Drupal بشكل جيد، فقد تكون CMS بدون رؤوس هي الخيار الصحيح.

أهداف الترحيل الشهيرة

CMS الأسعار (2026) الأفضل ل المحتوى API منحنى التعلم
Contentful $300-$2,500+/شهر فرق التحرير الكبيرة GraphQL + REST متوسط
Sanity $99-$949+/شهر (مخصص في الشركات) الفرق التي تقودها المطورون GROQ + GraphQL منخفض-متوسط
Storyblok $109-$449+/شهر احتياجات التحرير البصري REST + GraphQL منخفض
Strapi (استضافة ذاتية) مجاني (استضافة ذاتية) / $29+/شهر (سحابي) الفرق التي تريد السيطرة REST + GraphQL متوسط
Payload CMS مجاني (استضافة ذاتية) / $35+/شهر (سحابي) فرق TypeScript-first REST + GraphQL متوسط

نحن نعمل مع عدة منها من خلال ممارسة تطوير Headless CMS الخاصة بنا. يعتمد الخيار الصحيح على المهارات التقنية للفريق وتعقيد المحتوى والميزانية.

ترحيل المحتوى من Drupal 7 إلى Headless CMS

هذا أسهل فعلاً من الترحيل إلى Drupal 10/11 من بعض النواحي. أنت غير مقيد بإطار عمل الترحيل الخاص بـ Drupal. النهج النموذجي:

  1. تصدير محتوى Drupal 7 عبر Drush أو استعلامات قاعدة البيانات المباشرة
  2. تحويل البيانات إلى نموذج محتوى CMS الهدف الخاص بك باستخدام scripts (Python و Node.js يعملان بشكل جيد)
  3. الاستيراد عبر API إدارة CMS
  4. التحقق والإصلاح للمراجع والوسائط والعلاقات
# Simple Drupal 7 content export via database
import mysql.connector
import json

db = mysql.connector.connect(
    host="localhost",
    user="drupal",
    password="yourpassword",
    database="drupal7_db"
)

cursor = db.cursor(dictionary=True)
cursor.execute("""
    SELECT n.nid, n.title, n.created, n.changed, n.status,
           fdb.body_value, fdb.body_summary
    FROM node n
    LEFT JOIN field_data_body fdb ON n.nid = fdb.entity_id
    WHERE n.type = 'article' AND n.status = 1
    ORDER BY n.created DESC
""")

articles = cursor.fetchall()

with open('articles_export.json', 'w') as f:
    json.dump(articles, f, default=str, indent=2)

print(f"Exported {len(articles)} articles")

الجزء الصعب ليس التصدير. إنه نقل نموذج محتوى Drupal 7 (مع نظام الحقول الخاص به والمراجع الكيانية والمصطلحات taxonomy والفقرات) إلى هياكل بيانات CMS جديدة. خطط هذا ليستغرق وقت تحليل كبير.

الخيار 4: مزودو الدعم الموسع (شراء الوقت)

إذا كنت في حاجة فعلاً إلى وقت أكثر — وأحياناً تفعل ذلك، خاصة مع دورات الميزانية والأولويات التنظيمية — يمكن لمزودي الدعم الموسع الحفاظ على موقع Drupal 7 الخاص بك مصححاً أثناء تخطيطك.

المزودون الرئيسيون الذين يقدمون دعم Drupal 7 الموسع

  • Tag1 Consulting — من أكثرها التحديد. إنهم ينقلون تصحيحات الأمان ويوفرون الصيانة المستمرة. تختلف الأسعار حسب تعقيد الموقع لكن توقع $30K-$80K/سنة.
  • Acquia — توفر دعم Drupal 7 الموسع من خلال منصتها، حالياً حتى عام 2026 لعملاء الشركات.
  • mySociety / D7 LTS Contributors — دعم موسع مدفوع بالمجتمع من خلال برنامج Drupal 7 Extended Support.

هذه استراتيجية جسر شرعية، وليست حلاً طويل الأجل. سأحدده بحد أقصى 12-18 شهراً. كل شهر تقضيه على Drupal 7 يزيد من تعقيد الترحيل مع توسع الفجوة بين D7 والمنصات الحديثة.

تخطيط الترحيل: إطار عمل خطوة بخطوة

إليك الإطار الذي أستخدمه مع كل ترحيل للشركات. إنه ليس براقاً، لكنه يعمل.

المرحلة 1: الفحص (2-4 أسابيع)

  • فحص المحتوى: كم عدد أنواع المحتوى؟ كم عدد العقد لكل نوع؟ ما مدى تعقيد نموذج المحتوى؟ هل تستخدم Paragraphs أو Field Collections أو Entity Reference؟
  • فحص الوحدة: أدرج كل وحدة contrib ومخصص. صنفها كـ: لديها معادل D10 أو تحتاج استبدال مخصص أو يمكن حذفها. أستخدم drush pm:list --status=enabled والمرجعية المتقاطعة مع drupal.org.
  • فحص التكامل: ما الأنظمة الخارجية التي يتحدث معها Drupal؟ بوابات الدفع و CRM وتسويق التسويق الآلي ومزودو SSO؟
  • تحديد الأداء الأساسي: وثق مقاييس الأداء الحالية. ستحتاجها للمقارنة.
  • فحص دور المستخدم: كم عدد سير العمل الافتتاحي الموجود؟ ما الأذونات التي تهم؟

المرحلة 2: قرار الهندسة المعمارية (2-3 أسابيع)

بناءً على الفحص الخاص بك، قرر أي من الخيارات الأربعة مناسب. هذا قرار هندسة معمارية حقيقي يجب أن ينطوي على قيادة الهندسة وأصحاب المصلحة في المحتوى ومن يتحكم في الميزانية.

المرحلة 3: إثبات المفهوم (3-6 أسابيع)

قبل الالتزام بترحيل كامل، قم ببناء إثبات مفهوم يغطي:

  • أنواع محتوى 2-3 مهاجرة إلى المنصة الجديدة
  • سير العمل الافتتاحي الأكثر تعقيداً الذي تم إعادة إنتاجه
  • تكامل حرج واحد متصل
  • معايير الأداء على المكدس الجديد

هنا حيث ستكتشف الأشياء التي لم يذكرها أحد أثناء الفحص. هناك دائماً شيء.

المرحلة 4: الترحيل الكامل (3-12 شهراً)

هذا هو العمل الفعلي. حدد الأولويات بلا رحمة. لا يحتاج كل شيء من Drupal 7 إلى المجيء معها. في تجربتي، يمكن حذف 20-30% من المحتوى والوظائف على موقع Drupal 7 الإنتاجي النموذجي أثناء الترحيل.

المرحلة 5: ضمان الجودة والإطلاق (2-4 أسابيع)

التحويلات حرجة. كل URL على موقع Drupal 7 الخاص بك له قيمة بحث يحتاج إلى عنوان 301 تحويل إلى الموقع الجديد. استخدم تصدير وحدة path_redirect و globalredirect كنقطة بداية، ثم قم بالزحف إلى الموقع القديم باستخدام Screaming Frog لبناء خريطة تحويل كاملة.

استراتيجية ترحيل المحتوى

ترحيل المحتوى يستحق قسمه الخاص لأنه حيث تنحرف معظم الترحيلات.

مشكلة حقل الجسم

حقول الجسم في Drupal 7 عادة ما تكون فوضى من HTML. ستجد أنماط مضمنة ومسارات صور مشفرة تماماً و iframes المضمنة وأحياناً PHP خام (إذا كان شخص ما يفعل تمكين وحدة المرشح PHP — رعب أمني حقيقي). قبل الترحيل، تحتاج إلى تحديد: تنظيفها أو نقل الفوضى؟

توصيتي: نظفها. اكتب scripts تحويل التي:

  • تجريد الأنماط المضمنة
  • تحويل العلامات <img> إلى مراجع وسائط صحيحة
  • إصلاح الروابط الداخلية لاستخدام بنية URL الجديدة
  • تحويل أي رموز embed WYSIWYG إلى الشكل الجديد

ترحيل الوسائط

تتعامل مواقع Drupal 7 مع الوسائط بطرق مختلفة جداً. يستخدم البعض وحدة الوسائط (1.x أو 2.x)، والبعض يستخدم حقول ملف عادية، والبعض يستخدم رموز وسائط مضمنة في حقول الجسم. قم بتعيين كل نمط معالجة وسائط قبل البدء في كتابة كود الترحيل.

إذا كنت تنتقل إلى CMS بدون رؤوس، فستحتاج أيضاً إلى تحديد مكان وجود ملفات الوسائط. معظم CMSs بدون رؤوس لديها إدارة أصول مدمجة، أو يمكنك استخدام DAM مثل Cloudinary أو imgix.

محتوى متعدد اللغات

إذا كان موقع Drupal 7 الخاص بك يستخدم i18n أو entity_translation أو content_translation، فإن تعقيد الترحيل يقريباً يتضاعف. كان نظام Drupal 7 متعدد اللغات ... دعنا نقول "إبداعي". هياكل البيانات غير متسقة وتتطلب تعيين حذر.

تقديرات التكلفة والجدول الزمني

سأعطيك أرقاماً حقيقية بناءً على المشاريع التي كنت متورطاً فيها أو أملك معرفة مباشرة بها.

تعقيد الموقع ترحيل Drupal 10/11 ترحيل Headless CMS واجهة أمامية بدون رؤوس + خادم Drupal
صغير (5-10 أنواع محتوى، <1K صفحة، 2-3 وحدات مخصصة) $80K-$150K، 3-6 أشهر $60K-$120K، 2-4 أشهر $100K-$180K، 3-6 أشهر
متوسط (10-20 نوع محتوى، 1K-10K صفحة، 5-10 وحدات مخصصة) $200K-$500K، 6-12 شهراً $150K-$350K، 4-8 أشهر $200K-$450K، 5-10 أشهر
كبير (20+ نوع محتوى، 10K+ صفحة، 10+ وحدات مخصصة، متعدد اللغات) $500K-$1.5M+، 12-24 شهراً $300K-$800K، 6-14 شهراً $400K-$1M+، 8-18 شهراً

هذه تكاليف محملة بالكامل تشمل الاكتشاف والتطوير والترحيل وضمان الجودة وإدارة المشروع. سيختلف الألف بناءً على تكوين الفريق (في البيت مقابل الوكالة) والموقع الجغرافي وكمية التنظيف التي تقوم بها مقابل البحث كما هو.

هل تريد الحصول على تقدير أكثر تحديداً لوضعك؟ نحن نقوم بتقييمات الترحيل التي تعطيك صورة واضحة للنطاق والتكلفة.

الأخطاء الشائعة التي رأيتها الفرق تقترفها

محاولة عمل 1:1 إعادة إنتاج. موقع Drupal 7 الخاص بك تراكم 10+ سنوات من الفوضى. لا تهاجر كل ذلك. استخدم الترحيل كفرصة للتبسيط.

التقليل من تقدير جهد التحويل. عملت على ترحيل حيث نسي الفريق التحويلات حتى أسبوعين قبل الإطلاق. كان لديهم 45,000 URL للخريطة. لا تكن هذا الفريق.

عدم إشراك أصحاب المصلحة في المحتوى في وقت مبكر. الأشخاص الذين يستخدمون CMS يومياً سيكون لديهم آراء قوية حول النظام الجديد. شملهم في المرحلة 1، وليس المرحلة 4.

اختيار منصة بناءً على الميزات وليس القدرة على الفريق. أفضل CMS هو الذي يمكن لفريقك الحفاظ عليه بالفعل. إذا لم يكن لديك خبرة Drupal، فإن ترحيل Drupal 10/11 بدون تعيين له يعد إعداداً للتكرار من هذا الموقف في 5 سنوات.

تشغيل الأنظمة المتوازية لفترة طويلة. قم بتعيين تاريخ cutover ثابت. تشغيل القديم والجديد بالتوازي مكلف وملبك.

تخطي تجميد المحتوى. أثناء الدفع النهائي للترحيل، تحتاج إلى تجميد المحتوى على الموقع القديم. خطط لذلك. تواصل معها. يكره مؤلفو المحتوى، لكنها ضرورية للتأكد من أن شيء لا يضيع.

الأسئلة الشائعة

ماذا يحدث إذا استمررت في تشغيل Drupal 7 بعد انتهاء الحياة؟ لن يتوقف موقعك فجأة عن العمل. لكنك لن تتلقى تصحيحات أمان، مما يعني أن أي ثغرات مكتشفة حديثاً ستبقى غير مصححة إلى أجل غير مسمى. هذا خطر حقيقي — مواقع Drupal هي أهداف متكررة للهجمات الآلية. ستواجه أيضاً مشاكل توافق متزايدة مع تقدم إصدارات PHP ولا تسقط مزودو الاستضافة الدعم لإصدارات PHP الأقدم. بالنسبة لأي منظمة لديها متطلبات الامتثال (PCI و HIPAA و SOC 2 و GDPR)، فإن تشغيل البرامج غير المدعومة انتهاك مباشر.

هل يمكنني الترقية مباشرة من Drupal 7 إلى Drupal 11؟ نعم، يدعم Migrate API الترحيل المباشر من Drupal 7 إلى Drupal 10 أو 11. لا تحتاج إلى الخطوة خلال Drupal 8 و 9. ومع ذلك، هذه ليست "ترقية" بالمعنى التقليدي — إنها إعادة بناء موقعك على المنصة الجديدة مع ترحيل المحتوى. لا تحمل المواضيع والوحدات المخصصة والتكوينات مباشرة.

كم يستغرق الترحيل النموذجي Drupal 7؟ بالنسبة لموقع شركة متوسط الحجم، خطط لـ 6-12 شهراً من البداية إلى الإطلاق. يمكن القيام بمواقع أصغر مع وظائف مخصصة محدودة في 3-4 أشهر. يمكن أن تستغرق المواقع الكبيرة والمعقدة مع محتوى متعدد اللغات وتكاملات واسعة والتخصيص الثقيل 12-24 شهراً. ستعطيك مرحلة الفحص تقدير أكثر دقة بكثير لوضعك المحدد.

هل من الجدير ترحيل Drupal 10/11 أم يجب أن أتحول إلى منصة CMS مختلفة؟ يعتمد على فريقك واحتياجاتك. إذا كان لديك خبرة Drupal في المنزل، فإن نموذج المحتوى الخاص بك مناسب جيداً لنظام كيانات Drupal، وتحتاج إلى نقاط قوة Drupal (الأذونات المعقدة والمتعدد اللغات والمتعدد المواقع)، فإن البقاء في النظام البيئي منطقي. إذا كنت تعاني من صعوبة تعيين مطوري Drupal، فإن موقعك هو في المقام الأول موقع تسويقي بدون سير عمل افتتاحي معقد، أو كنت تريد الانتقال إلى هندسة معمارية بدون رؤوس، فقد يكون CMS مختلف استثماراً أفضل.

ما أرخص خيار للترحيل بعيداً عن Drupal 7؟ الدعم الموسع من مزود مثل Tag1 ($30K-$80K/سنة) هو الخيار الأرخص على المدى القصير، لكنه لا يحل المشكلة الأساسية. بالنسبة للترحيل الفعلي، فإن الانتقال إلى CMS بدون رؤوس مثل Sanity أو Storyblok مع واجهة أمامية ثابتة يميل إلى أن يكون أكثر فعالية من حيث التكلفة للمواقع الأبسط، بدءاً من $60K-$120K.

هل ستتأثر تصنيفات SEO الخاصة بي بالترحيل؟ يمكنها أن تكون، لكن التخطيط الصحيح يقلل التأثير. العوامل الحرجة هي: الحفاظ على هياكل URL (أو تنفيذ 301 تحويلات صحيحة لكل URL مفهرس)، والحفاظ على بيانات وسم البيانات وترميز البيانات المنظمة، والتأكد من أن الموقع الجديد يحمل بسرعة على الأقل مثل الموقع القديم (من الناحية المثالية أسرع)، وإرسال خرائط sitemap محدثة إلى Google Search Console. رأيت الترحيلات المنفذة بشكل جيد تحسن SEO بسبب سرعة صفحة أفضل وتجربة الجوال. رأيت أيضاً ترحيلات سيئة تؤثر على الحركة بنسبة 50% لأن شخص ما نسي التحويلات.

هل يمكنني ترحيل المحتوى بشكل تدريجي أم يجب أن يكون كل شيء في وقت واحد؟ الترحيل التدريجي ممكن وغالباً ما يكون أفضل للمواقع الكبيرة. مع هندسة معمارية بدون رؤوس، يمكنك إنشاء الواجهة الأمامية الجديدة وترحيل أقسام الموقع واحداً تلو الآخر، باستخدام قواعد proxy معكوسة لتوجيه حركة المرور إلى الخلفية المناسبة. هذا يقلل المخاطر ويسمح لك بالتحقق من صحة كل قسم قبل المضي قدماً. المقايضة هي زيادة التعقيد التشغيلي أثناء فترة الترحيل.

هل يجب أن أفكر في WordPress كهدف ترحيل؟ WordPress هو خيار قابل للحياة للمواقع الأبسط، لكن سأكون حذراً لحالات الاستخدام الإنتاجية. إذا كان موقع Drupal 7 الخاص بك يحتوي على أنواع محتوى معقدة أو أذونات دقيقة أو سير عمل افتتاحي متطور، فسيبدو WordPress بمثابة خطوة للخلف. نموذج محتوى WordPress (المنشورات والصفحات وأنواع المنشورات المخصصة) أبسط من نظام كيانات Drupal. بالنسبة لفرق الشركات، سأنظر بجدية أكبر إلى Drupal 10/11 أو CMS بدون رؤوس مناسب. وقال أن WordPress مع ACF Pro وواجهة أمامية بدون رؤوس يمكن أن يعمل بشكل جيد للمواقع التي تركز على التسويق.