Your Drupal 7 multi-site instance runs 23 franchise locations on shared infrastructure that hasn't seen a security patch since February 2025. You're staring at a D7-to-D10 migration that's actually 23 separate rebuilds—each location's custom modules, each theme override, each content type rebuilt by hand. Drupal 9 teams faced this exact rebuild pain moving from D7. Now D10-to-D11 brings another wave of breaking changes, and your network multiplies every compatibility failure by the number of sites you manage. We've pulled multi-site networks off Drupal and onto Next.js + Supabase in under 90 days. The architecture difference explains why teams are making this permanent move—and why going back becomes unthinkable once you see deployment at scale.

I want to be clear upfront: Drupal is not bad software. It powered — and still powers — some of the most important websites on the internet. But multi-site Drupal in 2026 is a fundamentally different proposition than it was in 2015. The ecosystem has shifted, the economics have changed, and the developer talent pool has migrated to JavaScript. If you're an IT team or agency managing a Drupal multi-site network for a university, hospital system, government agency, or multi-location business, this article is for you.

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

Drupal Multi-Site Is Dead: What Multi-Location Businesses Use Instead

لماذا Drupal Multi-Site آخذ في الاختفاء

كانت فكرة Drupal multi-site رائعة في عام 2010. قاعدة كود واحدة، خادم واحد، عدة مواقع تشارك الوحدات والسمات. بالنسبة للجامعات التي تحتوي على 50 موقع إدارة أو أنظمة المستشفيات التي تحتوي على 30 موقع عيادة، كان الخيار المنطقي. يمكنك إدارة كل شيء من لوحة تحكم إدارية واحدة، والضغط على التحديثات مرة واحدة، والحفاظ على التناسق عبر الشبكة.

قد تحطم هذا النموذج تحت وزن تطور Drupal نفسه.

المشكلة الأساسية ليست أي مشكلة واحدة — إنها التأثير المركب لخمس ضغوط متزامنة: تكاليف الترقية، وتوافق الوحدات، ونقص المواهب، وتوقعات الأداء، واقتصاديات الاستضافة. كل واحد وحده سيكون قابلا للإدارة. معا، يجعلان Drupal multi-site غير قابل للعمل بالنسبة لمعظم المنظمات.

ضريبة الترقية التي تكسر الميزانيات

وصل Drupal 7 إلى نهاية الحياة في يناير 2025. هذا ليس إهمالا ناعما — فهذا يعني عدم وجود المزيد من تصحيحات الأمان، ولا مزيد من دعم المجتمع، والتعرض المفعل للثغرات الأمنية لكل موقع في شبكتك. إذا كنت تقوم بتشغيل D7 multi-site، فأنت تحمل مخاطر حقيقية.

لكن هنا الجزء الذي يحرق: الترقية من Drupal 7 إلى Drupal 10 أو 11 ليست ترقية. إنها إعادة بناء. أعاد Drupal 8 كتابة المعمارية بالكامل، والانتقال من نموذج PHP الإجرائي إلى PHP موجه للكائنات القائم على Symfony. سماتك D7؟ ذهب. وحداتك المخصصة؟ أعد كتابتها. ملفات النماذج الخاصة بك؟ ابدأ من جديد باستخدام Twig.

على موقع واحد، هذا مشروع مؤلم لكن قابل للإدارة. في شبكة multi-site من 20 موقع، إنها 20 إعادة بناء. حتى إذا كانت المواقع تشارك سمة أساسية، فمن المحتمل أن يكون لكل موقع تخصيصات — أنواع محتوى مخصصة، وتكوينات Views، والكتل، وتخطيطات نوع الفقرة التي تحتاج إلى انتباه فردي.

تخبر الأرقام القصة:

  • ترقية D7 إلى D10 لموقع واحد: $30,000–$80,000 حسب التعقيد
  • ترقية D7 إلى D10 لشبكة من 20 موقع: $200,000–$600,000+ (ليس مضاعفا بسيطا بسبب الكود المشترك، لكن بعيد عن تكلفة موقع واحد)
  • ترقية D10 إلى D11: أقل درامية ولكن تتضمن تغييرات جوهرية حول مكونات Symfony 7، متطلبات PHP 8.3، وإزالة API المهملة

والدورة لا تتوقف. التزمت Drupal بإصدارات رئيسية سنوية، مما يعني تغييرات جوهرية سنوية. كل إصدار يرفع الحد الأدنى لإصدار PHP، ويهمل APIs، ويتطلب من مؤلفي الوحدات تحديث الكود الخاص بهم. بالنسبة لشبكة multi-site، يؤدي هذا إلى إنشاء سير عمل ترقية دائم.

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

فخ توافق الوحدة

تأتي قوة Drupal من نظام الوحدات المساهمة فيه. قد تستخدم تثبيتة multi-site نموذجية 40-80 وحدة مساهمة — Views، Paragraphs، Webform، Pathauto، Metatag، Media، Layout Builder، وعشرات أخرى.

إليك المشكلة: في إعداد multi-site، جميع المواقع تشارك نفس قاعدة الكود. هذا يعني أن كل وحدة يجب أن تكون متوافقة مع كل موقع في نفس الوقت. عندما يتوقف مؤلف الوحدة عن دعم Drupal 9 (الذي وصل بالفعل إلى نهاية الحياة في نوفمبر 2023) ويدعم فقط D10/D11، لا يمكنك الترقية الانتقائية للوحدة لموقع واحد. أنت تقوم بترقية الوحدة لجميع المواقع، أو لا شيء.

هذا يخلق جمود التبعيات. تريد الترقية إلى Module A لأنه يحتوي على تصحيح أمني حاسم، لكن الإصدار الجديد من Module A يتطلب Drupal 10.3+، وقاعدة الكود الخاصة بك على 10.1 لأن Module B لم يصدر نسخة متوافقة مع 10.3 حتى الآن. اضرب هذا في 60 وحدة و20 موقع، وأنت تقضي الآن مجموعات كاملة على اختبارات التوافق.

نظام الوحدات المساهمة آخذ أيضا في الانكماش. وفقا لإحصائيات Drupal.org، عدد الوحدات التي يتم صيانتها بنشاط آخذ في الانخفاض منذ عام 2020. انتقل العديد من مؤلفي الوحدات إلى منصات أخرى أو توقفوا عن تحديث الوحدات الخاصة بهم. مجتمع Drupal أصغر مما كان قبل خمس سنوات، والاتجاه آخذ في التسارع.

Drupal Multi-Site Is Dead: What Multi-Location Businesses Use Instead - architecture

نقص مواهب Drupal حقيقي

هذا هو الذي يشعر به أصحاب الوكالات ومديرو تكنولوجيا المعلومات بشكل أكثر حدة. العثور على مطوري Drupal في عام 2026 صعب حقا.

يتطلب Drupal مجموعة مهارات محددة: PHP (متقدم)، Symfony، Twig templating، نظام Drupal entity/field، API plugin، إدارة التكوين (قائم على YAML)، وأنابيب العرض. الأمر ليس أن هذه مهارات سيئة — إنها ببساطة نادرة بشكل متزايد. المطورون الخارجون من bootcamps وبرامج CS يتعلمون React و Next.js و TypeScript. إنهم لا يتعلمون Drupal.

أسعار السوق تعكس هذا:

دور مطور Drupal مطور Next.js
Junior $80–$120/hr $60–$90/hr
Mid-level $120–$170/hr $80–$130/hr
Senior $170–$220/hr $120–$170/hr
Available talent pool آخذ في الانكماش آخذ في النمو بسرعة
Average time to hire 6-12 أسابيع 2-4 أسابيع

أنت تدفع أكثر للمطورين الذين يصعب العثور عليهم، تعمل في نظام بيئي به موارد مجتمع أقل. هذا ليس موضعا مستداما لأي منظمة.

قمنا ببناء ممارسة تطوير Next.js لدينا خصيصا لأن هذا هو حيث تقاربت المواهب والطلب.

الأداء: عرض PHP مقابل تسليم Edge

يخدم Drupal الصفحات من خلال عرض PHP. كل طلب يضرب الخادم، ويبدأ Drupal، ويستعلم عن قاعدة البيانات، ويعمل من خلال خط أنابيب العرض، ويعيد HTML. حتى مع طبقات caching (Varnish, Redis, Drupal's internal page cache)، للعمارة سقف أداء.

نقاط Lighthouse النموذجية على تثبيتات Drupal multi-site الإنتاجية:

  • الأداء: 55–70
  • LCP (أكبر عملية طلاء محتوى): 2.5–4.5 ثانية
  • CLS (تحول التخطيط التراكمي): 0.1–0.3
  • TTFB (الوقت حتى البايت الأول): 800ms–2.5s (حسب الاستضافة)

Next.js على Vercel مع ISR (Incremental Static Regeneration) أو SSG (Static Site Generation):

  • الأداء: 90–100
  • LCP: 0.8–1.5 ثانية
  • CLS: 0–0.05
  • TTFB: 50–200ms (edge-cached)

هذا ليس اختلافا هامشيا. إنها فجوة جيل. Google's Core Web Vitals هي عامل تصنيف، والفرق في الأداء بين Drupal وإطار عمل frontend حديث على البنية الأساسية للحافة يمكن قياسه في تصنيفات البحث.

بالنسبة للمشاريع التجارية متعددة المواقع، هذا مهم أكثر. كل صفحة موقع هي صفحة هبوط SEO محلية. إذا كانت صفحة عيادة Dallas الخاصة بك تحميل في 4 ثوان بينما ينقل المنافس إلى 1.2 ثانية، Google تلاحظ.

مقارنة التكاليف: استضافة Drupal مقابل المكدس الحديث

يتطلب Drupal multi-site استضافة Drupal مُدارة. تحتاج إلى PHP و MySQL/MariaDB وcaching على مستوى الخادم والمثالي منصة تفهم بنية ملف Drupal وتكوين multisite. الخيارات الرئيسية:

  • Acquia Cloud: $800–$3,000/شهر لـ multi-site
  • Pantheon: $300–$1,500/شهر حسب الخطة وعدد المواقع
  • Platform.sh: $500–$2,000/شهر
  • Self-managed على AWS/GCP: $200–$800/شهر للبنية الأساسية، بالإضافة إلى $2,000–$5,000/شهر لـ sysadmin لإدارتها

مكدس الحداثة الموصى به لمتعدد المواقع:

  • Vercel Pro: $20/شهر
  • Supabase Pro: $25/شهر
  • المجموع: $45/شهر

هذا $540/سنة مقابل $3,600–$36,000/سنة. حتى إذا أضفت CDN للوسائط ($20/شهر) وأداة مراقبة ($30/شهر)، فأنت على $1,140/سنة. يدفع توفير الاستضافة وحده للترقية في غضون السنة الأولى.

أن نكون عادلين: تصعيد تسعير Vercel و Supabase مع الاستخدام. قد يرى موقع متعدد المواقع عالي الحركة فواتير Vercel بقيمة $100–$300/شهر و Supabase بقيمة $50–$100/شهر. حتى عند الحد الأعلى، أنت بـ $4,800/سنة — لا تزال جزء كبير من استضافة Drupal المدارة.

رأسا برأس: Drupal Multi-Site مقابل Next.js + Supabase

عامل Drupal Multi-Site Next.js + Supabase
تكلفة الترقية (لكل إصدار رئيسي) $200K–$600K لـ 20 موقع $0–$5K (تحديثات تبعية طفيفة)
تكلفة الاستضافة السنوية $3,600–$36,000 $540–$4,800
معدل ساعة المطور $120–$220/hr $80–$170/hr
الوقت لإضافة موقع جديد 2–4 أسابيع 1–3 أيام
موقف الأمان يتطلب تصحيحا مستمرا، قاعدة كود مشتركة = مخاطر مشتركة صفحات ثابتة مولدة، لا خادم للاستغلال
نقاط Lighthouse للأداء 55–70 90–100
دعم i18n وحدة Drupal i18n (تكوين معقد) next-intl + locale columns (مباشر)
تحرير المحتوى واجهة مستخدم إدارة Drupal Supabase dashboard، تطبيق إدارة مخصص، أو headless CMS
النشر SSH/Git deploy إلى خادم واحد Git push → Vercel auto-deploy مع preview URLs

مسار الترقية: Drupal إلى Next.js + Supabase

إليك العملية الفعلية التي نتبعها عند ترقية شبكات Drupal multi-site. هذا ليس مشروع نهاية أسبوع، لكنه محدد وقابل للتنبؤ به جيدا.

الخطوة 1: تصدير المحتوى من Drupal

يعتمد النهج على إصدار Drupal الخاص بك.

Drupal 10/11: استخدم وحدة JSON:API (المضمنة في core) لتصدير المحتوى برمجيا:

# تصدير جميع العقد من نوع 'location'
curl https://your-drupal-site.com/jsonapi/node/location?page[limit]=50 \
  -H "Authorization: Basic BASE64_CREDENTIALS" \
  > locations.json

Drupal 7: لا توجد REST API مدمجة. ستحتاج إلى الاستعلام عن قاعدة البيانات مباشرة. يخزن Drupal 7 المحتوى عبر جداول متعددة — node، field_data_*، field_revision_*، وجداول taxonomy.

-- تصدير عقد D7 location مع بيانات الحقل
SELECT 
  n.nid,
  n.title,
  n.created,
  n.changed,
  fdb.body_value AS body,
  fda.field_address_value AS address,
  fdp.field_phone_value AS phone,
  fdl.field_latitude_value AS latitude,
  fdl.field_longitude_value AS longitude
FROM node n
LEFT JOIN field_data_body fdb ON n.nid = fdb.entity_id
LEFT JOIN field_data_field_address fda ON n.nid = fda.entity_id
LEFT JOIN field_data_field_phone fdp ON n.nid = fdp.entity_id
LEFT JOIN field_data_field_location fdl ON n.nid = fdl.entity_id
WHERE n.type = 'location'
AND n.status = 1;

هذا فوضى — تخزين حقل EAV (Entity-Attribute-Value) من Drupal 7 يعني أنك تنضم جدول منفصل لكل حقل. لكنه يعمل.

الخطوة 2: تحويل بيانات Drupal إلى مخطط Supabase

نموذج بيانات Drupal لا يرسم 1:1 إلى مخطط علائقي نظيف. إليك كيفية التعامل مع التحويلات الرئيسية:

أنواع الفقرات → حقول JSONB

يخزن Drupal Paragraphs محتوى التخطيط المرن كـ entities مرجعية. في Supabase، نستخدم عمود JSONB:

CREATE TABLE locations (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  slug TEXT UNIQUE NOT NULL,
  site_id TEXT NOT NULL, -- يحدد الموقع/الموقع
  title TEXT NOT NULL,
  body TEXT,
  address JSONB, -- {street, city, state, zip, country}
  phone TEXT,
  coordinates GEOGRAPHY(POINT, 4326),
  page_sections JSONB, -- يحل محل أنواع الفقرات
  meta JSONB, -- البيانات الوصفية للـ SEO
  locale TEXT DEFAULT 'en',
  published BOOLEAN DEFAULT false,
  created_at TIMESTAMPTZ DEFAULT now(),
  updated_at TIMESTAMPTZ DEFAULT now()
);

يخزن حقل page_sections JSONB ما كانت Drupal Paragraphs تتعامل معه:

[
  {
    "type": "hero",
    "heading": "مرحبا بك في موقعنا في Dallas",
    "image": "/images/dallas-hero.webp",
    "cta": {"text": "احجز موعدا", "url": "/dallas/book"}
  },
  {
    "type": "text_block",
    "body": "<p>تخدم عيادتنا في Dallas المجتمع منذ عام 2008...</p>"
  },
  {
    "type": "staff_grid",
    "staff_ids": ["uuid-1", "uuid-2", "uuid-3"]
  }
]

Drupal Views → استعلامات Supabase + Server Components

Drupal Views هو في الأساس منشئ استعلامات بصري. في المكدس الجديد، تصبح استعلامات Supabase تُستدعى من Next.js Server Components:

// app/[location]/page.tsx -- يحل محل Drupal View
import { createClient } from '@/lib/supabase/server'

export default async function LocationPage({ 
  params 
}: { 
  params: { location: string } 
}) {
  const supabase = await createClient()
  
  const { data: location } = await supabase
    .from('locations')
    .select('*')
    .eq('slug', params.location)
    .eq('published', true)
    .single()

  if (!location) notFound()

  const { data: nearbyLocations } = await supabase
    .rpc('nearby_locations', {
      lat: location.coordinates.coordinates[1],
      lng: location.coordinates.coordinates[0],
      limit_count: 3
    })

  return (
    <main>
      <LocationHero location={location} />
      <SectionRenderer sections={location.page_sections} />
      <NearbyLocations locations={nearbyLocations} />
    </main>
  )
}

مستخدمو Drupal → مصادقة Supabase

إذا كانت مواقع Drupal الخاصة بك تحتوي على مصادقة مستخدم (بوابات المرضى، تسجيلات الطالب، إلخ)، فإن Supabase Auth يتعامل مع هذا مع الدعم المدمج لبريد إلكتروني/كلمة مرور وروابط magic وموفري OAuth و Row Level Security:

-- Row Level Security: يمكن للمستخدمين فقط رؤية بيانات خاصتهم
ALTER TABLE patient_records ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users see own records" ON patient_records
  FOR SELECT USING (auth.uid() = user_id);

Drupal i18n → next-intl + Locale Columns

نظام multilingualDrupal قوي لكن معقد — ترجمة المحتوى، ترجمة الواجهة، ترجمة التكوين، والكشف عن اللغة يعملون جميعا عبر أنظمة منفصلة. مع next-intl و Supabase، إنه أبسط:

// استعلم عن محتوى مترجم
const { data } = await supabase
  .from('locations')
  .select('*')
  .eq('slug', params.location)
  .eq('locale', params.locale)
  .single()

Taxonomy → Tags/Categories في Supabase

تصبح مفردات taxonomy Drupal جداول بحث بسيطة مع جدول يقاطع كثير من الكثيرين:

CREATE TABLE categories (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  vocabulary TEXT NOT NULL, -- 'service_type', 'specialty', إلخ
  name TEXT NOT NULL,
  slug TEXT NOT NULL
);

CREATE TABLE location_categories (
  location_id UUID REFERENCES locations(id),
  category_id UUID REFERENCES categories(id),
  PRIMARY KEY (location_id, category_id)
);

الخطوة 3: إعادة بناء القوالب في Next.js + Tailwind

هذا هو حيث يحدث العمل الفعلي للـ frontend. ننشئ مكتبة مكون تعرض أقسام الصفحة JSONB ديناميكيا. كل قالب Drupal يصبح مكون React. نستخدم Tailwind CSS للتصميم، مما يعني أن المصممين الخاصين بك يمكنهم العمل مع فئات الأداة بدلا من الصراع مع طبقة موضوع Drupal.

الخطوة 4: 301 إعادة توجيه كل عنوان URL

هذا حرج. تتبع عناوين URL الخاصة بـ Drupal أنماط مثل /node/123، /location/dallas-tx، أو أي شيء Pathauto أنشأته. كل عنوان URL واحد يحتاج إلى إعادة توجيه 301 إلى ما يعادله الجديد من Next.js. ننشئ هذه من قاعدة بيانات Drupal:

// next.config.js
module.exports = {
  async redirects() {
    return [
      // تم إنشاؤه من جدول url_alias Drupal
      { source: '/node/1234', destination: '/locations/dallas', permanent: true },
      { source: '/locations/dallas-tx-clinic', destination: '/locations/dallas', permanent: true },
      // ... المئات أكثر
    ]
  }
}

الخطوة 5: النشر وإيقاف التشغيل

نشر إلى Vercel، التحقق من جميع عمليات إعادة التوجيه، تأكيد استقرار مقاييس SEO (توقع تقلب 2-4 أسابيع)، ثم إيقاف خوادم Drupal. احتفظ بنسخة احتياطية من قاعدة البيانات — لن تحتاجها أبدا، لكنك ستنام بشكل أفضل.

الصناعات التي تترك Drupal (وما ينتقلون إليه)

الجامعات

كانت التعليم العالي نقطة قوة Drupal. أحبت الجامعات multi-site لأن كل قسم وكلية وبرنامج يمكن أن يحصل على موقعه الخاص تحت مظلة واحدة. لكن تكاليف الترقية قاسية للمؤسسات التي تحتوي على 50-200 تحت الموقع. نحن نرى الجامعات تنتقل إلى Next.js مع خيارات headless CMS مثل Sanity أو Contentful لتحرير المحتوى، أو إلى مكدسنا المفضل من Next.js + Supabase للمؤسسات التي تريد التحكم الكامل في بياناتها. يغطي عملنا headless CMS development هذه الهجرات بالضبط.

أنظمة المستشفيات

تحتاج المنظمات الصحية إلى الامتثال HIPAA، و Drupal على الاستضافة المشتركة هو صداع الامتثال. توفر المكدسات الحديثة مع Supabase (التي توفر امتثال SOC 2 Type II ويمكن استضافتها ذاتيا لمتطلبات HIPAA) موقف أمان أفضل مع عدم الحاجة إلى النفقات العامة التشغيلية. تصبح صفحة كل موقع عيادة صفحة مولدة بشكل ثابت بدون سطح هجوم على الخادم.

وكالات حكومية

كانت مواقع حكومية من متبني Drupal في وقت مبكر — اشتهر WhiteHouse.gov بأنه يعمل على Drupal. لكن متطلبات الامتثال FedRAMP وعملية ATO (Authority to Operate) لاستضافة Drupal المستندة إلى الخادم مكلفة. معايير توليد المواقع الثابتة وأرضيات JAMstack تقلل سطح الامتثال بشكل كبير. انتقلت عدة وكالات إلى Next.js مع تصدير ثابت أو إلى Astro للمواقع الغنية بالمحتوى المعلوماتي.

منظمات الإعلام

يحتاج الناشرون إلى السرعة — سرعة تحميل الصفحة والسرعة في سير عمل التحرير. لا يمكن لـ Drupal experience التحريري، على الرغم من التحسينات مع Layout Builder، أن ينطبق على التجارب التحريرية الحديثة المتاحة مع منصات headless CMS. والفرق في الأداء بين عرض Drupal وتسليم الصفحات الثابتة على الحافة هو الفرق بين القراء البقاء والارتداد.

ما تبدو عليه البنية الأساسية بعد الترقية

الحالة النهائية لعمل متعدد المواقع تبدو هكذا:

┌─────────────────────────────────────────────┐
│                  Vercel                       │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐    │
│  │ /dallas  │ │ /austin  │ │ /houston │    │
│  │ (SSG)    │ │ (SSG)    │ │ (SSG)    │    │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘    │
│       └─────────────┼─────────────┘          │
│                     │                        │
│            Next.js App Router                │
│            (مكونات مشتركة)                  │
└─────────────────────┬───────────────────────┘
                      │
              ┌───────┴───────┐
              │   Supabase    │
              │  ┌──────────┐ │
              │  │locations │ │
              │  │staff     │ │
              │  │services  │ │
              │  │reviews   │ │
              │  │media     │ │
              │  └──────────┘ │
              │  + Auth       │
              │  + Storage    │
              │  + Edge Funcs │
              └───────────────┘

إضافة موقع جديد؟ إدراج صف في جدول locations، وإضافة محتوى أقسام الصفحة، والموقع أعاد البناء عبر ISR. لا توفير موقع Drupal جديد، لا تكوين DNS، لا إعداد Apache vhost. فقط البيانات.

إذا كانت هذه البنية الأساسية تهمك، فقد وثقنا النهج والتسعير لهذه الأنواع من الترقيات في صفحة الأسعار الخاصة بنا. للحديث عن شبكة Drupal المحددة الخاصة بك، تواصل معنا.

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

هل Drupal 7 آمنة لا تزال في الاستخدام في عام 2026؟ لا. وصل Drupal 7 إلى نهاية الحياة في يناير 2025. لا يعود يتلقى تصحيحات الأمان من فريق أمان Drupal. هناك موردو دعم ممتدة من الجهات الخارجية، لكنهم مكلفون ($500–$2,000/شهر) ويغطون فقط core — ليس الوحدات المساهمة. إذا كنت لا تزال على D7، يجب عليك اعتبار الترقية ملحة، وليست اختيارية.

كم يستغرق ترقية Drupal إلى Next.js؟ بالنسبة لموقع واحد، توقع 4–8 أسابيع. بالنسبة لشبكة multi-site بـ 10–20 موقع، خطط لـ 3–6 أشهر مع نهج مرحلي — هاجر المواقع على دفعات، بدءا بالمواقع عالية الحركة. تعني مكتبة المكون المشتركة أن كل موقع لاحق يهاجر بشكل أسرع من السابق.

هل سأفقد تصنيفات SEO عند الترقية من Drupal؟ ستشهد تقلبات مؤقتة — عادة 2–4 أسابيع — حيث تزحف Google و reindexes صفحاتك. عمليات إعادة التوجيه 301 التي تم تنفيذها بشكل صحيح غير قابلة للتفاوض. شهدنا معظم المواقع تتعافى إلى تصنيفاتها قبل الترقية في غضون 30 يوم، والكثير تتجاوزها في غضون 60 يوم بسبب تحسين نقاط Core Web Vitals.

ماذا عن تجربة تحرير محتوى Drupal؟ يحتاج المحررون غير التقنيين إلى نظام إدارة محتوى. هذا قلق صحيح. لوحة معلومات Supabase تعمل لفرق تقنية، لكن المحررين غير التقنيين يحتاجون عادة إلى واجهة أودية. الخيارات تشمل: بناء لوحة تحكم مخصصة مع Next.js (2–3 أسابيع من العمل الإضافي)، استخدام headless CMS مثل Sanity أو Contentful كطبقة تحرير مع Supabase كمخزن بيانات، أو استخدام APIs auto-generated من Supabase مع أداة مثل Retool أو Appsmith لـ admin interfaces سريع.

هل يمكن لـ Supabase التعامل مع الامتثال HIPAA لمنظمات الرعاية الصحية؟ Supabase Cloud متوافق مع SOC 2 Type II. بالنسبة إلى HIPAA، ستحتاج إما إلى Business Associate Agreement (BAA) مع Supabase — اتصل بفريق المبيعات الخاص بهم — أو استضف ذاتيا Supabase على البنية الأساسية الخاصة بك التي تتوافق مع HIPAA (AWS GovCloud، Azure Government، إلخ). تضيف الاستضافة الذاتية تعقيد تشغيلي ولكنها تمنحك تحكما كاملا في إقامة البيانات والامتثال.

ما هو الفرق الحقيقي في التكلفة بين Drupal multi-site و Next.js + Supabase؟ بالنسبة لشبكة من 20 موقع على Acquia أو Pantheon، تنفق عادة $12,000–$36,000/سنة على الاستضافة وحدها. Next.js على Vercel + Supabase للشبكة نفسها يعمل $540–$4,800/سنة. مع الأخذ في الاعتبار دورة ترقية Drupal ($200K–$600K كل 2–3 سنوات) مقابل تكاليف ترقية قريبة من الصفر مع Next.js، فإن الفرق في TCO لمدة خمس سنوات غالبا ما يكون $500K+.

هل يمكن أن أهاجر بشكل تدريجي، أو يجب أن يكون الكل مرة واحدة؟ الترقية التدريجية تعمل بشكل جيد. استخدم Vercel's rewrites لبروكسي مسارات محددة إلى موقع Drupal القديم الخاص بك بينما تخدم صفحات مهاجرة من Next.js. هاجر موقع واحد في كل مرة. هذا النهج أقل خطورة ويسمح لك بالتحقق من الصحة من المكدس الجديد قبل الالتزام الكامل. فعلنا هذا مع شبكات من 30+ موقع حيث لم تكن ترقية big-bang ممكنة.

ماذا يحدث لوظيفة وحدة Drupal المساهمة الخاصة بي؟ كل وحدة ترسم إلى شيء في المكدس الجديد. Webform يصبح React Hook Form + Supabase inserts. Pathauto يصبح Next.js dynamic routes. Metatag يصبح Next.js Metadata API. Views يصبح استعلامات Supabase. Search API يصبح Supabase full-text search أو خدمة مثل Meilisearch. لا تختفي الوظيفة — إنها تنتقل إلى تطبيق أكثر قابلية للصيانة. كتبنا خريطط ترقية لـ 50 وحدة Drupal الأكثر شيوعا كجزء من ممارسة headless CMS migration الخاصة بنا.