دليل الترحيل من TYPO3 إلى Drupal: دليل عملي للمطورين
هجرة TYPO3 إلى Drupal: دليل عملي للمطورين
إذا كنت قد حدقت في خلفية TYPO3 وفكرت، "يجب أن توجد طريقة أفضل من هذه"، صدقني، أنت بعيد جداً عن الوحيد. TYPO3 لديه قوته – لن أجادل في ذلك. لقد كان نظام إدارة المحتوى المفضل للعديد من المؤسسات والمواقع الحكومية الأوروبية لأكثر من عشرين سنة. لكن، لنكن صادقين هنا، المشهد الذي يواجهه المطورون قد تغير بشكل كبير. العديد من المنظمات تجد أن Drupal يوفر إعداداً أكثر حداثة، وجماعة أقوى، ومساراً أسهل نحو بنى معمارية بدون رأس/منفصلة.
كنت عميقاً في عدة عمليات هجرة من TYPO3 إلى Drupal على مدار السنتين الماضيتين، وكانت رحلة معقدة جداً في فك تشابك نماذج محتوى العالم الحقيقي. عادة ما تكون فوضى معقدة. هذا الدليل هو ما أتمنى أن يكون قد أُعطي لي قبل هجرتي الأولى. سأغطي جميع التفاصيل التقنية الدقيقة، وضروريات التخطيط، وتلك الألغام الزعاجة التي يمكن أن تدمر الجدول الزمني الخاص بك إذا لم تكن منتبهاً.
جدول المحتويات
- لماذا تترك المنظمات TYPO3
- TYPO3 مقابل Drupal: مقارنة صادقة
- تدقيق ما قبل الهجرة والتخطيط
- نمذجة المحتوى: ربط TYPO3 بـ Drupal
- أدوات الهجرة والنهج التقني
- التعامل مع TypoScript وتطبيقات TYPO3
- هيكل URL والحفاظ على SEO
- الانتقال إلى بدون رأس بعد الهجرة
- تقديرات الجدول الزمني والتكلفة والموظفين
- قائمة التحقق بعد الهجرة
- الأسئلة الشائعة

لماذا تترك المنظمات TYPO3
لنكن صريحين: TYPO3 ليس نظام إدارة محتوى سيء. إنه مرن بشكل كبير، ويتعامل مع إعدادات متعددة المواقع ومتعددة اللغات بشكل أصلي، ويفتخر بقاعدة معجبين متعصبة خاصة في منطقة DACH. إذاً لماذا يقفز الناس السفينة؟
أسمع نفس الأسباب تقريباً في كل مرة:
توفر المطورين. خارج وسط أوروبا، العثور على مطوري TYPO3 صعب مثل العثور على إبرة في كومة قش. Drupal، من ناحية أخرى، يدعي حوالي 1.3 مليون مطور عالمياً، وفقاً لتقرير مجتمع Drupal.org لعام 2024. TYPO3؟ ليس كثيراً. إذا قرر كبار مطوري TYPO3 الخاصين بك مغادرة، قد يستغرق ملء تلك الوظائف وقتاً طويلاً جداً.
زخم الاقتصاد الحيوي. مع إطلاق Drupal 11 في نهاية عام 2024، كانت هناك خطوات كبيرة في واجهة المسؤول، نظام وصفات جديد، وإمكانيات قوية موجهة نحو API. بالتأكيد، TYPO3 v13 قوي، لكن معدل الابتكار في Drupal، خاصة حول الإعدادات بدون رأس، أسرع بشكل ملحوظ.
البنية المعمارية بدون رأس/منفصلة. هل تخطط للتعامل مع المحتوى في واجهة أمامية رائعة بـ Next.js أو Astro؟ JSON:API وإضافات GraphQL الخاصة بـ Drupal هي محترفون متمرسون. TYPO3 لديه تطبيقه الخاص بدون رأس، لكنه أقل نضجاً مع دعم أصغر.
إجمالي تكلفة الملكية. استضافة TYPO3 عادة ما تضرب المحفظة بشدة. تعني البنية الأساسية المتخصصة أنك قد تنتهي بك الحال إلى إنفاق المزيد. Drupal مرتاح تقريباً في أي مكان من Pantheon إلى Acquia، حتى مكدس LAMP الأساسي يبقيها تعمل بسلاسة.
TYPO3 مقابل Drupal: مقارنة صادقة
قبل الانجراف رأساً في خطوة، تأكد من أن Drupal سيحل بصدق نقاط الألم الخاصة بك. إليك الملخص اعتباراً من 2025:
| الميزة | TYPO3 v13 | Drupal 11 |
|---|---|---|
| نمذجة المحتوى | مرن لكنه يميل إلى TCA | نظام Entity/Field مع واجهة إدارة الحقول |
| متعدد اللغات | دعم أصلي ممتاز | دعم أصلي متساوي الجودة |
| متعدد المواقع | متعدد المواقع القياسي مع أشجار محتوى | ممكن، غالباً ما يكون أفضل مع Domain Access أو عمليات تثبيت منفصلة |
| بدون رأس/API | لديه تطبيق بدون رأس | JSON:API الأساسي، GraphQL contrib |
| النماذج | يتميز بنماذج Fluid + TypoScript | يعمل على نماذج Twig |
| نظام الإضافات/الوحدات | حوالي 1,800 إضافة على TER | 50,000+ وحدة على Drupal.org |
| واجهة المسؤول | قوية، لكن قديمة (تحصل على تحديث في v13) | أنيقة وحديثة في Drupal 11 |
| مجتمع المطورين | حوالي 500 مساهم نشط | 8,000+ مساهم نشط |
| خيارات الاستضافة | استضافة ذاتية أو متخصصة | استضافة ذاتية، Pantheon، Acquia، Platform.sh، Lagoon |
| متطلبات PHP | PHP 8.2+ | PHP 8.3+ |
| معدل الوكالة النموذجي | €100-180/hr (منطقة DACH) | $80-200/hr (عالمي) |
نموذج شجرة الصفحات في TYPO3 جوهرة نادرة. المحررون المعجبون بإدارة التسلسلات الهرمية المعقدة للصفحات في TYPO3 قد يجدون أسلوب Drupal - مزيج أنواع المحتوى والتصنيف - يتطلب قليلاً من التعديل. قم بجدولة بعض التدريب للمحررين لتسهيل هذا الانتقال.
تدقيق ما قبل الهجرة والتخطيط
تحدد هذه المرحلة مصير معظم الهجرات. كل شيء في التخطيط، وليس في المرات التقنية.
جرد المحتوى
ابدأ بتدقيق كل شيء في إعداد TYPO3 الخاص بك:
- الصفحات: اسحب تلك شجرة الصفحات، مع توثيق كل
doktype(نوع صفحة) لديك قيد التشغيل. - عناصر المحتوى: كل
CType(نوع محتوى) يحتاج إلى الاهتمام - سواء كان نصاً أو نصاً مع صورة أو HTML أو أشياء مخصصة عبرmaskأوcontent_defender. - التطبيقات: لاحظ كل تطبيق لديك. اكتشف ما إذا كان هناك ما يعادله في Drupal.
- مراجع الملفات: طبقة FAL (File Abstraction Layer) الخاصة بـ TYPO3 تتعامل مع الوسائط. قم بتعيين هذه إلى مواقع الوسائط في Drupal.
- مستخدمو الخلفية والأذونات: مجموعات مستخدمي الخلفية المعقدة في TYPO3 مع وصول على مستوى الصفحة والحقل يجب أن تُترجم بدقة إلى أدوار Drupal والأذونات.
إليك استعلام SQL سهل لملخص عنصر المحتوى من قاعدة البيانات الخاصة بك في TYPO3:
SELECT CType, COUNT(*) as count
FROM tt_content
WHERE deleted = 0 AND hidden = 0
GROUP BY CType
ORDER BY count DESC;
بهذا، تحصل على نظرة سريعة على أنواع المحتوى التي تتعامل معها. في حالة واحدة، اكتشفت مثيل TYPO3 يفتخر بـ 40+ نوع عنصر محتوى مخصص، حيث تم استخدام أقل من اثني عشر بنشاط. لا تسحب الوزن الميت فوق.
ما الذي تبقيه، وما الذي تتخلص منه
هنا فرصتك لتنظيف الفوضى. استخدم أداة تدقيق المحتوى مثل Screaming Frog أو Sitebulb للبحث عن:
- الصفحات التي لا تحصل على حركة في العام الماضي
- المحتوى المكرر أو شبه المتطابق
- الروابط الداخلية المكسورة
- ملفات الوسائط اليتيمة
عادةً، هناك قطع محتوى بنسبة 30-50% في عمليات الهجرة الكبرى من TYPO3. صفحات أقل تعني هجرات أسرع.

نمذجة المحتوى: ربط TYPO3 بـ Drupal
اجمع تفاصيل أكمامك. هذا هو رفع الأثقال الفكري الثقيل. TYPO3 و Drupal يتعاملان مع المحتوى بطرق مختلفة جداً.
نموذج TYPO3
TYPO3 يدور حول الصفحات. كل شيء مخفي في شجرة صفحة. عناصر المحتوى (السجلات في tt_content) توضع على الصفحات في أعمدة (colPos). السجلات المخصصة المحددة من خلال نماذج Extbase أو TCA تجلس في جداول منفصلة لكنها عادة ما تكون مرتبطة من الصفحات.
نموذج Drupal
Drupal يدور حول الكيانات. أنت تصنع أنواع محتوى (عقد الحزم)، لكل منها حقول مخصصة. الصفحات هي فقط واحدة من بين العديد. التصنيفات والفقرات (باستخدام وحدة Paragraphs) و Layout Builder تسود تكوين المحتوى المنظم.
التعيين
إليك جدول تعيين نموذجي أستخدمه كبوصلتي:
| مفهوم TYPO3 | معادل Drupal |
|---|---|
| صفحة (doktype: قياسي) | عقدة (نوع محتوى: صفحة) |
| صفحة (doktype: اختصار) | إعادة توجيه URL |
| صفحة (doktype: رابط) | عقدة مع حقل رابط أو إعادة توجيه |
| عنصر محتوى (CType: نص) | نوع فقرة أو حقل الجسم |
| عنصر محتوى (CType: صورة) | مرجع كيان الوسائط |
| عنصر محتوى (CType: textpic) | نوع فقرة مع نص + وسائط |
| عنصر محتوى (CType: gridelements) | قسم Layout Builder |
| مرجع ملف FAL | كيان الوسائط |
| sys_category | مصطلح التصنيف |
| fe_users | كيان مستخدم Drupal |
| be_users | كيان مستخدم Drupal مع دور المسؤول |
| قالب TypoScript | قالب Twig |
| إضافة Extbase | وحدة Drupal مخصصة |
| عناصر محتوى Mask/DCE | أنواع الفقرات |
أكبر تحول؟ نقل عناصر المحتوى إلى الفقرات. TYPO3 يكدس عناصر المحتوى في أعمدة الصفحة، والتي تعيين جيداً لوحدة Paragraphs الخاصة بـ Drupal. محررون يكدسون صفحات من أنواع فقرات قابلة لإعادة الاستخدام - إنه سلس بشكل مفاجئ.
أدوات الهجرة والنهج التقني
Drupal's Migrate API روك. لكن رأس لأعلى، إنه يفتقد إلى إضافة مصدر TYPO3 الأصلية. سيتعين عليك تحضير بعض إضافات المصدر المخصصة لسحب من قاعدة بيانات TYPO3.
النهج 1: هجرة قاعدة البيانات المباشرة
قم بتوصيل Migrate API الخاصة بـ Drupal مباشرة بقاعدة بيانات MySQL/MariaDB الخاصة بك بـ TYPO3:
// مثال إضافة مصدر الهجرة لصفحات TYPO3
namespace Drupal\typo3_migrate\Plugin\migrate\source;
use Drupal\migrate\Plugin\migrate\source\SqlBase;
use Drupal\migrate\Row;
/**
* @MigrateSource(id = "typo3_pages")
*/
class Typo3Pages extends SqlBase {
public function query() {
return $this->select('pages', 'p')
->fields('p', ['uid', 'title', 'slug', 'abstract', 'doktype', 'crdate', 'tstamp'])
->condition('p.deleted', 0)
->condition('p.hidden', 0)
->condition('p.doktype', [1, 4], 'IN');
}
public function fields() {
return [
'uid' => $this->t('معرف الصفحة'),
'title' => $this->t('عنوان الصفحة'),
'slug' => $this->t('رابط URL'),
'abstract' => $this->t('الملخص/الموجز'),
];
}
public function getIds() {
return ['uid' => ['type' => 'integer']];
}
public function prepareRow(Row $row) {
// تحميل عناصر المحتوى المرتبطة
$pid = $row->getSourceProperty('uid');
$content = $this->select('tt_content', 'tt')
->fields('tt')
->condition('tt.pid', $pid)
->condition('tt.deleted', 0)
->orderBy('tt.sorting')
->execute()
->fetchAll();
$row->setSourceProperty('content_elements', $content);
return parent::prepareRow($row);
}
}
أنا أحب هذا النهج. يتعلق الأمر بالحصول على التحكم الكامل ويسمح لك بالتعامل مع غريبة TYPO3 (مثل الحذف الناعم ومراكز العمل) في القاعدة الخاصة بك.
النهج 2: تصدير/استيراد عبر JSON أو XML
بعض الفرق تختار تصدير محتوى TYPO3 إلى تنسيقات منظمة (يقول، من خلال تطبيقات TYPO3 مخصصة أو أوامر CLI) ثم استيرادها إلى Drupal. بالتأكيد، يضيف طبقة أخرى لكنها تأتي في متناول اليد إذا كنت حذراً من الحفاظ على الاتصالات المباشرة بقاعدة البيانات أثناء الهجرة.
النهج 3: هجين مع المراجعة اليدوية
هل لديك موقع أصغر (أقل من 500 صفحة)؟ القيام بهجرة بيانات منظمة تلقائياً بينما تصنع يدوياً صفحات الهبوط الرئيسية يمكن أن تعمل بشكل سحري. قد يبدو بدائياً، لكن عندما يكون محتوى متشابكاً مع منطق عرض TYPO3 الخاص به، غالباً ما ينتج عن الهجرة الآلية هراء.
التعامل مع TypoScript وتطبيقات TYPO3
TypoScript
دعنا نقطع إلى الملخص: TypoScript لا يهاجر. إنها لغة إعدادات خاصة بـ TYPO3، بدون نقيض حقيقي في أي مكان آخر. وظيفتك هي توثيق ما يفعله كل قالب TypoScript بعبارات بسيطة ثم إعادة بنائه كنماذج Twig وإعدادات Drupal. إنه مرهق لكنه ضروري.
التطبيقات
إليك مقارنة سهلة للتطبيقات الشائعة في TYPO3 ونقاباتها في Drupal:
| تطبيق TYPO3 | معادل Drupal |
|---|---|
| news | نوع محتوى أساسي + طرق عرض |
| powermail | وحدة Webform |
| solr (ext:solr) | API البحث + Solr |
| realurl / routing | Pathauto + التوجيه الأساسي |
| gridelements | Layout Builder أو Paragraphs |
| mask | Paragraphs |
| tt_address | نوع محتوى مخصص أو CiviCRM |
| ke_search | API البحث |
| femanager | وحدة المستخدم + مخصص |
| cal/events | نوع محتوى مخصص + طرق عرض |
تطبيقات Extbase المخصصة تحتاج إلى إعادة كتابة كوحدات Drupal. لا توجد اختصارات هناك - تأكد من ميزانيتها.
هيكل URL والحفاظ على SEO
اخطئ فيه، وتفقد حركة البحث العضوية. شاهدت منظمات تفقد ما يصل إلى 40% من حركة البحث الخاصة بهم بعد الهجرة بسبب عمليات إعادة توجيه سيئة التعامل.
الخطوات
- تصدير جميع عناوين URL من TYPO3. استخدم أداة CLI أو زاحف لكل URL مفهرس.
- قم بتعيينها إلى عناوين URL الخاصة بـ Drupal. استخدم Pathauto الخاصة بـ Drupal لإنشاء بدائل URL، والالتزام بـ URLs الموجودة.
- قم بإنشاء عمليات إعادة توجيه لكل ما يتغير. نشر وحدة Redirect في Drupal. لعدد ضخم من عمليات إعادة التوجيه، استيراد عبر CSV.
- التعامل مع بادئات اللغة. يستخدم TYPO3
/de/,/en/,/fr/- تأكد من أن إعدادات لغة Drupal تعكس هذا. - إرسال الخرائط الموقعية المحدثة إلى وحدة تحكم البحث من Google على الفور.
# مثال صيغة استيراد إعادة التوجيه CSV لوحدة Redirect الخاصة بـ Drupal
source,redirect,status_code,language
/alte-seite,/new-page,301,de
/old-page/subpage,/new-page/subpage,301,en
/kontakt,/contact,301,de
نصيحة احترافية: احتفظ بمثيل TYPO3 القديم حياً، وإن كان للقراءة فقط، لمدة ثلاثة أشهر على الأقل بعد الهجرة. ستكتشف عناوين URL التي تم تفويتها.
الانتقال إلى بدون رأس بعد الهجرة
Drupal يلمع مع مساره إلى واجهة أمامية منفصلة. مع Drupal 11، وحدة JSON:API قوية كصخرة، والنظام الإيكولوجي بدون رأس Drupal ازدهار.
إذا كنت تتفكر في نهج بدون رأس - وفي عام 2025، بالنسبة لمعظم مواقع محتوى، فمن الجدير بالنظر - فقد تعمقنا في هذا بدقة على /solutions/headless-cms-development.
إقران الواجهات الأمامية الشهيرة مع Drupal:
- Next.js — الرائد.
next-drupalبواسطة Chapter Three يسهل الأمور. نناقشها بشكل مكثف على /capabilities/nextjs-development. - Astro — مثالي لمواقع غنية بالمحتوى ليست ثقيلة جداً على جانب العميل. انظر /capabilities/astro-development.
- Nuxt — إذا كان Vue ملعبك.
جمال الهجرة الأولى إلى Drupal هو الإطلاق مع واجهة Twig الافتراضية الخاصة بـ Drupal. لاحقاً، يمكنك الانتقال إلى واحدة منفصلة. لا تحاول كلا الحركتين في نفس الوقت - هذا يطلب فوضى المشروع.
تقديرات الجدول الزمني والتكلفة والموظفين
أرقام حقيقية من المشاريع التي كنت جزءاً منها، أو لديّ بيانات دقيقة من (2024-2025):
| حجم الموقع | الصفحات | الجدول الزمني | نطاق الميزانية | الفريق |
|---|---|---|---|---|
| صغير | <500 صفحة | 2-3 شهور | $30,000-60,000 | 2-3 مطورين |
| متوسط | 500-5,000 صفحة | 4-6 شهور | $60,000-150,000 | 3-5 مطورين |
| كبير | 5,000-50,000 صفحة | 6-12 شهر | $150,000-400,000 | 5-8 مطورين |
| المؤسسة | 50,000+ صفحة | 12-18 شهر | $400,000-1,000,000+ | 8-15 مطورين |
هذه تشمل كل شيء من الاكتشاف، نمذجة المحتوى، الهجرة، الموضوع الأمامي، QA، وتدريب المحرر. الصيانة المستمرة لم تُغطَ هنا.
تفكر بأشياء محددة لحالتك؟ تحقق من /pricing أو تواصل مباشرة.
قائمة التحقق بعد الهجرة
لا تتخطى هذه القائمة. صدقني.
- تحقق من جميع عمليات إعادة التوجيه. تأكد من أنها 301s.
- تحديث وحدة تحكم البحث من Google مع خريطة الموقع الجديدة الخاصة بك.
- اختبر جميع النماذج: اتصال، النشرة الإخبارية، تسجيل الدخول.
- تأكد من دقة محتوى متعدد اللغات لكل لغة.
- هاجر ملفات الوسائط بدقة مع نص بديل وبيانات التعريف.
- تحقق من أذونات المحرر لكل دور.
- التقط مقاييس الأداء (Core Web Vitals).
- تحقق من تتبع التحليلات (أحداث GA4، الأهداف).
- تكوين واختبار CDN/التخزين المؤقت.
- تمكين رؤوس الأمان (CSP، HSTS).
- اختبر أنظمة النسخ الاحتياطي والتعافي من الكوارث.
- أكمل التدريب والمحررين وقدم التوثيق.
- احتفظ بمثيل TYPO3 القديم متاحاً في وضع القراءة فقط.
الأسئلة الشائعة
كم من الوقت تستغرق عادة هجرة من TYPO3 إلى Drupal؟
بالنسبة للمواقع متوسطة الحجم (500-5,000 صفحة)، حوالي 4-6 أشهر من البداية إلى الإطلاق. الشهر الأول؟ اكتشاف بحت ونمذجة محتوى. يستغرق نص الهجرة عادة 6-8 أسابيع من العمل. جودة الضمان وتدريب المحرر؟ احسب شهراً آخر. إذا كانت إعداد معقد متعدد اللغات ومتعدد المواقع مع تطبيقات مخصصة، فأنت تنظر إلى 9-12 شهراً.
هل يمكنني هاجرة محتوى TYPO3 تلقائياً، أم أنها يدوية؟
محتوى منظم مثل الصفحات وسجلات الأخبار أو الفئات؟ بالتأكيد وظيفة آلية مع Drupal's Migrate API. لكن منطق عرض محتوى معقد قد يحتاج بعض TLC اليدوية. معظم الهجرات؟ حوالي 70-80% آلية، 20-30% يدوية.
هل سأفقد تصنيفات Google الخاصة بي أثناء الهجرة؟
لا إذا كنت حريصاً على عمليات إعادة التوجيه الخاصة بك. اضبط 301s لأي تغييرات URL، تمسك بهيكل URL الخاص بك بأفضل ما يمكنك، قدم تلك الخرائط الموقعية المحدثة فوراً. ستحتمل رؤية انخفاض، قل 2-6 أسابيع. لكن الارتداد طبيعي - المواقع عادة ما ترتد إلى مستويات ما قبل الهجرة في 4-8 أسابيع وغالباً ما ترى تحسينات في ثلاثة أشهر بسبب أداء أفضل.
هل من الصعب على محرري المحتوى تعلم Drupal أكثر من TYPO3؟
مختلف، ليس أصعب. أولئك الذين اعتادوا على نموذج شجرة الصفحات في TYPO3 قد يحتاجون إلى وقت مع منهج Drupal المركزي على الكيانات. وحدة الفقرات تقدم تجربة بناء محتوى متشابهة نوعاً ما. تذكر ميزانية حوالي 2-3 أيام من التدريب للمحررين وزود لهم بوثائق محددة لنوع المحتوى وسير العمل.
ماذا يحدث لتطبيقات TYPO3 الخاصة بي أثناء الهجرة؟
كل تطبيق يستحق التقييم الفردي. كثير لديهم معادلات Drupal مباشرة (على سبيل المثال، powermail → Webform، ext:news → نوع محتوى مخصص + طرق عرض، ext:solr → API البحث + Solr). تطبيقات Extbase المخصصة؟ سوف تحتاج إعادة كتابة كاملة كوحدات Drupal. لا توجد مبدلات - ستحتاج إلى التخصيص.
هل يجب أن أذهب بدون رأس عند الهجرة من TYPO3 إلى Drupal؟
يعتمد على الأهداف والجدول الزمني الخاص بك. إذا كانت الحركة الخاصة بك مدفوعة بمخاوف المطور أو الحفاظ على الكود، ابدأ بسيط مع موضوع Twig الخاص بـ Drupal، استهدف بدون رأس لاحقاً. لكن إذا كان فريق الواجهة الأمامية الخاص بك يحب React أو إعداد مماثل، وتشتهي بنية تسليم حديثة، فكر في التخطيط بدون رأس من اليوم الأول. فقط تذكر: القيام بهجرات وتغييرات الواجهة الأمامية في نفس الوقت؟ هذا إقليم عالي المخاطر.
كيف أتعامل مع محتوى متعدد اللغات في الهجرة؟
إعداد لغة TYPO3 (sys_language_uid، l10n_parent) يتماشى بشكل جيد مع وحدة Content Translation الخاصة بـ Drupal. الخدعة؟ الارتقاء بربط اللغة بـ اللغة في النصوص البرمجية والتأكد من أن الحالات الافتراضية تتطابق مع توقعاتك. كن حذراً من محتوى مترجم جزئياً - أنماط overlay اللغة في TYPO3 (حرة، متصلة، صارمة) ليس لديها نقابل دقيقة في Drupal. قد تكون القرارات التحريرية حول الترجمات غير المكتملة ضرورية.
ما هو ROI لهجرة TYPO3 إلى Drupal؟
أين ROI؟ أساساً من تقليل نفقات المطور وتسريع عرض الميزات. تاريخياً، الفرق التي وجهتها رؤية حوالي قطع 20-40% في تكاليف التطوير في السنة الأولى، يرجع في الأساس إلى تجنيد الموهبة الأسهل وحمض وحدة أكبر الذي يقلل من الحاجة إلى التطوير المخصص. يمكن أن تكون تكاليف الهجرة الأولية ضخمة، لكن معظمهم يجب أن يكسروا حتى في غضون 18-24 شهراً.