السياق — توقف المبيعات ونهاية دعم Jira Data Center
أوقف Atlassian رسميًا بيع تراخيص Jira Data Center الجديدة للعملاء الجدد في 30 مارس 2026. يحتفظ عملاء Data Center الحاليون بإمكانية شراء توسّعات التراخيص والتجديدات حتى 30 مارس 2028، وبعد ذلك تختفي هذه الخيارات أيضًا. المرحلة النهائية هي EOL في 28 مارس 2029: في ذلك التاريخ، تدخل منتجات Data Center في وضع القراءة فقط. تبقى بياناتك متاحة للاطلاع، لكن أي إنشاء أو تعديل للتذاكر أو المشاريع أو الإعدادات يصبح مستحيلًا.
قد يبدو هذا الجدول الزمني مريحًا. في الواقع، تتطلّب هجرة إدارة المشاريع أسابيعَ من التحضير: جرد المشاريع النشطة، وأرشفة التذاكر القديمة، وإعادة تهيئة سير العمل، وتدريب الفرق، وفترة تشغيل متوازٍ للتحقق من الاستمرارية. الانتظار حتى 2028 يعني إجراء الهجرة تحت ضغط الموعد النهائي، مع خطر مرتفع لفقدان البيانات أو تعطّل الإنتاج.
خمسة أسباب للهجرة الآن بدلًا من الهجرة تحت الضغط
- تكلفة تراخيص Data Center لكل مستخدم — يفرض نموذج التسعير رسومًا لكل مستخدم نشط، مع مستويات سنوية تراجعاتها خارج نطاق سيطرتك. المغادرة الآن تتيح حساب TCO للحل الجديد بهدوء.
- جدول زمني مغلق، بلا مفاجآت — تاريخ 28 مارس 2029 نهائي. هجرة منجزة في 2026 أو 2027 تترك وقتًا للتشغيل المتوازي والتراجع المحتمل؛ هجرة منجزة في 2028 لا تترك لا هذا ولا ذاك.
- خطر وضع القراءة فقط عند نهاية الدعم — إن لم تُنجز هجرة نسختك قبل 28 مارس 2029، تفقد فرقك القدرة على إنشاء التذاكر أو تعديلها. يجب إقصاء هذا السيناريو مسبقًا.
- السيطرة على البيانات والنسخ الاحتياطية — على VPS بصلاحيات root، تختار تكرار النسخ الاحتياطية والتشفير ومدة الاحتفاظ وموقع البيانات. لا طرف ثالث يقرر مدة الاحتفاظ بدلًا منك.
- فرصة للتنظيف — الهجرة هي اللحظة المثالية لأرشفة المشاريع غير النشطة وتوحيد الحالات وأنواع التذاكر، والانطلاق من قاعدة نظيفة بدلًا من نقل سنوات من التراكمات.
- استقرار التكاملات — يجب إعادة بناء موصّلات Jira (CI/CD وConfluence وSlack والإضافات الخارجية) في كل الأحوال عند الانتقال إلى منصة جديدة. فعل ذلك اليوم يعني اختيار تكاملات مفتوحة تعتمد على API معيارية، بلا اعتماد على نظام بيئي احتكاري.
- إضافات لن تُنقل — أعلن Atlassian أن بعض إضافات Data Center لن تُنقل إلى ما بعد 2028؛ الميزات التي تعتمد عليها يجب تحديدها واستبدالها قبل نهاية الدعم.
المتطلبات الأساسية المقاسة قبل البدء
قبل الاختيار بين OpenProject وPlane، تحقّق أن VPS الخاص بك يستوفي الحدود الدنيا من متطلبات كل أداة. يتطلّب OpenProject معالجًا رباعي النواة بسرعة لا تقل عن 2 GHz و4 غيغابايت من الذاكرة لاستيعاب ما يصل إلى 200 مستخدم — هذا هو الإعداد الذي يوصي به الناشر للاستخدام الإنتاجي المستقر. دون ذلك، تتباطأ العمليات الخلفية (الإشعارات، تحديث الخصائص المحسوبة). يتطلّب Plane كحدٍّ أدنى 2 vCPU و4 غيغابايت من الذاكرة و20 غيغابايت من التخزين لنشر AIO (All-In-One) عبر Docker.
من حيث المتطلبات المشتركة: يجب إنتاج تصدير XML كامل من نسخة Jira Data Center والتحقق منه قبل لمس أي شيء على البيئة الهدف. صدّر مشروعًا بمشروع للنسخ الكبيرة — يفرض Jira حدودًا للحجم على التصديرات الشاملة قد تقطع الأرشيفات الكبيرة بصمت. احتفظ بنسخة احتياطية كاملة لجميع مشاريعك بما فيها المرفقات. يجب أن يكون VPS الهدف متاحًا عبر SSH بصلاحيات root، وأن يكون Docker مع docker compose الإصدار 2 مثبتًا أو قابلًا للتثبيت. خطّط أيضًا لنطاق أو نطاق فرعي وسجلات DNS المقابلة قبل توليد شهادات TLS.
OpenProject مقابل Plane — مقارنة المعايير الأساسية
| المعيار | OpenProject | Plane |
|---|---|---|
| الرخصة | GPL-3.0 | AGPL-3.0 |
| نجوم GitHub | ~15 900 | ~56 000 |
| ذاكرة RAM الدنيا (إنتاج) | 4 غيغابايت — رباعي النواة ≥ 2 GHz (حتى 200 مستخدم) | 4 غيغابايت — 2 vCPU، 20 غيغابايت تخزين |
| أداة هجرة Jira الرسمية | نعم — Beta (منذ OpenProject 17.4، مايو 2026) | استيراد أصلي من تصدير Jira XML |
| الواجهة | قريبة من Jira — حزم العمل، خرائط الطريق، Gantt مدمج | حديثة ومبسّطة — المشكلات والدورات والوحدات |
| منحنى التعلّم | معتدل — المفردات والمفاهيم قريبة من Jira | خفيف للفرق المعتادة على أدوات Agile الحديثة |
| المصادقة الموحّدة | LDAP وSAML مدمجان في الإصدار المجتمعي | LDAP مدمج في الاستضافة الذاتية؛ SAML متاح في الاستضافة الذاتية |
OpenProject — الهجرة عبر أداة Jira Migrator الرسمية
تصدير البيانات من Jira Data Center
في إدارة Jira، انتقل إلى النظام → النسخ الاحتياطي والتصدير. شغّل تصديرًا XML لكل مشروع على حدة للنسخ الكبيرة بدلًا من التصدير الشامل — يفرض Jira Data Center حدودًا للحجم قد تقطع التصديرات الكبيرة بصمت. أدرج المرفقات في التصدير. تحقّق من حجم الأرشيف المنتج وقارن عدد التذاكر المصدّرة مع العداد في قاعدة البيانات قبل المتابعة.
نشر OpenProject عبر Docker
على VPS، أنشئ مجلد عمل واسترجع ملف docker-compose.yml الرسمي لـ OpenProject. اضبط متغيرات البيئة الإلزامية: SECRET_KEY_BASE (أنشئ سلسلة عشوائية من 64 محرفًا)، OPENPROJECT_HOST__NAME (نطاقك)، OPENPROJECT_HTTPS=true. أطلق الحزمة بـ docker compose up -d وانتظر اكتمال ترحيل قاعدة البيانات (ظاهر في سجلات الحاوية web).
تهيئة Jira Migrator وتفعيله
أداة Jira Migrator في OpenProject متاحة في مرحلة Beta منذ الإصدار 17.4 (مايو 2026). في إدارة OpenProject، اذهب إلى الوحدات → هجرة Jira. تطلب الأداة أرشيف XML الخاص بـ Jira المصدَّر في الخطوة السابقة. قبل التشغيل، اقرأ القيود المعروفة الموثّقة على openproject.org/docs/installation-and-operations/jira-migration/ — قد تتطلّب بعض أنواع الحقول المخصصة أو تكوينات سير العمل معالجةً يدوية بعد الاستيراد.
تشغيل الهجرة ومراقبة التقدم
ابدأ الاستيراد من واجهة Jira Migrator. للنسخ الكبيرة (عشرات الآلاف من التذاكر)، قد تستغرق العملية عدة ساعات. راقب سجلات حاوية worker في OpenProject في الوقت ذاته: تظهر أخطاء الاستيراد هناك قبل تجميعها في تقرير نهاية الهجرة. لا توقف حزمة Docker أثناء الاستيراد.
التحقق من حزم العمل والمرفقات والحقول المخصصة
بعد اكتمال الاستيراد، يعرض Jira Migrator تقريرًا بعدد العناصر المستوردة والأخطاء المحتملة. تحقّق من عيّنة تمثيلية من حزم العمل: العنوان، الوصف، الحالة، النوع، المرفقات، تاريخ التعليقات. تحقّق من الحقول المخصصة من نوع نص وأرقام وتاريخ وقائمة اختيار — وهي الأنواع الأربعة التي تهاجر في مرحلة Beta. أنواع الحقول الحسابية أو التتالية لا تُهاجر تلقائيًا.
تهيئة المستخدمين والصلاحيات
يُنشئ Jira Migrator حسابات مستخدمي OpenProject المقابلة لحسابات Jira استنادًا إلى عنوان البريد الإلكتروني. المستخدمون الذين لا يتطابق بريدهم مع أي حساب OpenProject قائم يُنشأون كحسابات غير نشطة. فعّلهم يدويًا، وعيّنهم للمجموعات والمشاريع المناسبة، وهيّئ الأدوار. إذا كنت تستخدم LDAP أو SAML، صِل الدليل قبل هذه الخطوة لربط الحسابات بالمصادقة المركزية منذ أول تسجيل دخول.
تهيئة الإشعارات وخادم البريد
في الإدارة → إعدادات البريد، أدخل معلومات خادم SMTP. يرسل OpenProject إشعارات للإشارات وتغييرات الحالة وتواريخ الاستحقاق. أرسل رسالة اختبار قبل التحقق من الإعداد. حدّد تفضيلات الإشعارات الافتراضية للمستخدمين الجدد لتجنّب طوفان الرسائل فور فتح المنصة للفرق.
Plane — استيراد أصلي من تصدير Jira XML
تصدير البيانات من Jira Data Center
تابع بالطريقة ذاتها كما في OpenProject: تصدير XML لكل مشروع من إدارة Jira، متضمنًا المرفقات. إن تجاوزت نسختك حدود التصدير الشامل، قسّم التصدير بالمشاريع واستورد كل أرشيف بالتسلسل في Plane. احتفظ بأرشيفات XML الأصلية حتى التحقق الكامل من الهجرة.
نشر Plane في وضع AIO عبر Docker
يوفّر Plane نشرًا AIO (All-In-One) عبر Docker يجمع جميع الخدمات في تكوين مبسّط. استنسخ المستودع الرسمي، انسخ .env.example إلى .env واضبط على الأقل WEB_URL (نطاقك)، SECRET_KEY ومعاملات قاعدة البيانات. أطلق بـ docker compose -f docker-compose.yml up -d. الخدمات التي تبدأ تشمل واجهة Next.js، API Django، عامل Celery، قاعدة بيانات PostgreSQL وRedis.
الاستيراد من Jira XML في واجهة Plane
بعد الوصول إلى Plane، أنشئ مساحة عمل. اذهب إلى إعدادات مساحة العمل → أدوات الاستيراد → Jira. تطلب Plane رفع أرشيف XML المصدَّر من Jira. ينشئ الاستيراد مشروع Plane لكل مشروع Jira في الأرشيف، مع المشكلات والأوصاف والمرفقات والتعليقات. تُعيَّن حالات Jira إلى حالات Plane يمكن إعادة تسميتها بعد الاستيراد.
التحقق من المشكلات والمرفقات
بعد الاستيراد، تصفّح عيّنة من المشكلات لكل مشروع: العنوان، الوصف بصيغة Markdown، المرفقات، التعليقات التاريخية. تحقّق من التعيين الصحيح للحالات المخصصة. المشكلات التي تتجاوز مرفقاتها الحجم المسموح به في تصدير Jira قد تظهر بدون الملف المرفق — راجع تقرير الاستيراد في إعدادات مساحة العمل.
تهيئة الدورات والوحدات والأعضاء
تنظّم Plane العمل في دورات (ما يعادل Sprints في Jira) ووحدات (تجميعات موضوعية). هذه الهياكل لا تُستورد تلقائيًا من Jira — يجب إعادة إنشائها وفق التنظيم المطلوب للمنصة الجديدة. ادعُ أعضاء الفريق بالبريد الإلكتروني أو هيّئ SSO بـ SAML في إعدادات مساحة العمل قبل فتح الوصول لجميع المستخدمين.
ما لا تنقله الأداتان
قبل الإعلان عن الهجرة لفرقك، وثّق صراحةً ما لن يُنقل — فهذا المصدر الرئيسي للخيبة والمقاومة للتغيير.
أتمتة Jira وقواعدها (محفّزات تغيير الحالة، إعادة التعيين التلقائية، الانتقالات المشروطة) لا تُهاجر. لدى كل من OpenProject وPlane نظام أتمتة خاص بهما، لكن يجب إعادة تهيئته من الصفر. خطّط لورشة عمل مع الفرق لرسم خريطة الأتمتة القائمة قبل الهجرة.
التكاملات الخارجية — موصّلات Confluence، روبوتات Slack، Webhooks نحو أنظمة CI/CD، إضافات Jira Marketplace — يجب إعادة بنائها على API لـ OpenProject أو Plane. تعرض كلتا الأداتين API REST موثّقة، لكن منطق التكامل يجب إعادة كتابته.
سير عمل المشاريع ذات الشروط المعقدة (صلاحيات بالدور على كل انتقال، قيود التحقق) لا تُهاجر بواسطة Jira Migrator Beta. يتيح OpenProject إعادة تهيئة سير العمل الكاملة، لكن فقط عبر واجهة الإدارة — لا تلقائيًا عند الاستيراد.
بيانات Sprint التاريخية — السرعة، مخطط الاحتراق، الطاقة المخطَّطة مقابل الفعلية — لا تُنقل. يُحفظ تاريخ المشكلات والتعليقات، لكن مقاييس Agile المجمّعة تبقى في Jira. إن كانت لهذه البيانات قيمة للفريق، صدّرها بصيغة CSV من Jira قبل إغلاق النسخة.
أخيرًا، أنواع تذاكر Jira Service Management (الحوادث وطلبات الخدمة والمشكلات بالمفهوم ITSM) لا تتطابق مباشرةً مع أنواع المشكلات في الأداتين. إن كنت تستخدم Jira للتطوير والدعم ITSM معًا، قيّم ما إذا كان OpenProject أو Plane يغطيان احتياجاتك في ITSM، أو ما إذا كان يجب نشر حل مخصص (Zammad، Mattermost، Freshdesk ذاتي الاستضافة) جانبًا.
أنشئ دائمًا حساب مدير محلي قبل تفعيل مصادقة SSO (SAML أو LDAP). إذا تضمّن إعداد SSO خطأً — معرّف كيان خاطئ، شهادة منتهية الصلاحية، تعيين سمات غير صحيح — ستُقفل بشكل دائم من الواجهة عند أول محاولة تسجيل دخول عبر SSO. يتيح الحساب المحلي تصحيح الإعداد دون تدخّل على مستوى الخادم. في OpenProject، يجب إنشاء هذا الحساب قبل تفعيل وحدة LDAP في الإعدادات؛ في Plane، عطّل SSO أثناء التحقق من اتصال المدير. أجرِ أيضًا تصدير XML كاملًا لـ Jira ونسخة احتياطية كاملة لجميع المشاريع قبل أي عملية على البيئة الهدف.
استكشاف الأخطاء — الأخطاء الشائعة في الهجرة
تتكرر عدة أخطاء في الغالبية العظمى من هجرات Jira إلى OpenProject أو Plane.
معرّفات غير مُعيَّنة. تربط أداة Jira Migrator (وأداة استيراد Plane) مستخدمي Jira بالحسابات على المنصة الهدف عبر عنوان البريد الإلكتروني. إن كان مستخدم Jira يملك عنوان بريد مختلفًا عن حسابه في OpenProject أو Plane، تظهر تذاكره بلا مُعيَّن أو بمُعيَّن عام. الحل: أنشئ مسبقًا جميع حسابات المستخدمين بعناوين البريد الإلكترونية ذاتها الموجودة في Jira قبل تشغيل الاستيراد.
مرفقات مفقودة. تضمّن تصديرات Jira Data Center المرفقات في أرشيف ZIP، لكن Jira قد يفرض حدًا للحجم الإجمالي على التصديرات. إذا كان الأرشيف مقطوعًا، تغيب مرفقات التذاكر الأحدث. تحقّق من حجم الأرشيف المصدَّر وقارنه بمساحة القرص الفعلية لمجلد مرفقات Jira. للنسخ الكبيرة، صدّر بالمشروع وتحقّق مشروعًا بمشروع.
انتهاء مهلة التصديرات الكبيرة. للمشاريع ذات عشرات الآلاف من التذاكر، قد ينتهي وقت التصدير XML الشامل لـ Jira على مستوى الخادم. استخدم ميزة التصدير الجزئي بالمشروع المتاحة في واجهة إدارة Jira DC. ثم استورد كل أرشيف بالتسلسل في OpenProject أو Plane.
مشاكل ترميز المحارف في XML. قد تنتج تصديرات Jira التي تحتوي على محارف خاصة (علامات اقتباس طباعية، محارف ذات لهجات في بعض اللغات، رموز إيموجي في الأوصاف) ملفات XML مشوّهة. تحقّق من صحة أرشيف XML بأداة مثل xmllint قبل الاستيراد. إن ظهرت أخطاء ترميز، افتح الملف في محرر مع اكتشاف الترميز وصحّح التسلسلات غير الصالحة.
أخطاء Beta في Jira Migrator لـ OpenProject. الأداة في مرحلة Beta منذ الإصدار 17.4 (مايو 2026) وقد يتغيّر سلوكها بين الإصدارات الثانوية. في حال خطأ حاجب، راجع صفحة القيود المعروفة على openproject.org/docs/installation-and-operations/jira-migration/ قبل فتح تذكرة دعم. معظم أخطاء Beta موثّقة مع إجراء للتحايل.
VPS بصلاحيات root + OpenProject أو Plane — خروج منظّم من Jira Data Center
الهجرة من Jira Data Center ليست مشروعًا يمتد لأشهر إذا جرى التعامل معها بمنهجية. تصدير XML نظيف، وVPS مُحجَّم وفق متطلبات الأداة المختارة، ويوم عمل يكفيان لنقل المشكلات والمرفقات والحقول المخصصة الأساسية وتاريخ التعليقات إلى OpenProject أو Plane.
الاختيار بين الأداتين يعتمد على سياقك: OpenProject أقرب إلى Jira في مفاهيمه (حزم العمل، خرائط الطريق، Gantt) ولديه أداة Jira Migrator رسمية، مما يجعله الخيار الأقل مخاطرة للفرق المعتادة على مفردات Atlassian. Plane أكثر حداثةً في مقاربته وأوسع انتشارًا بين فرق التطوير التي تريد الانطلاق من أسس أخفّ.
في كلتا الحالتين، تستعيد السيطرة الكاملة: صلاحيات root على الخادم، نسخ احتياطية تحت إدارتك، غياب تسعير لكل مستخدم قابل للمراجعة أحاديًا من قِبل ناشر، وبيانات مستضافة في البنية التحتية التي تختارها. مغادرة Jira Data Center تتوقّف عن كونها قيدًا لتصبح فرصة لتنظيف أدوات إدارة مشاريعك.
