الترحيل

نعم. الترحيل المُساعَد مشمول في خطتَي Business و Pro: يتولّى فريقنا نقل موقعك دون انقطاع الخدمة.

نعم. يتيح لك مساعد الترحيل تجميع نقل نطاقاتك (عبر رمز EPP) وحسابات cPanel الخاصة بك في طلب موجَّه واحد — مثالي لاستعادة محفظة كاملة بأكملها. لكل استضافة، اختر الطريقة: رابط نسخة احتياطية (‎.tar.gz) أو نقل مباشر من cPanel القديم (باستخدام بيانات الدخول الخاصة بك، التي تُستعمل أثناء العملية ولا تُحفظ أبدًا).

لا. نُجهّز عملية النقل على خوادمنا ثم نحوّل DNS بعد التحقّق من كل شيء، لضمان انتقال دون انقطاع ملحوظ.

ننقل ملفاتك وقواعد بياناتك وحسابات بريدك الإلكتروني لإعادة بناء بيئتك كما هي تمامًا.

يستغرق الترحيل عادةً من 24 إلى 72 ساعة حسب حجم الموقع، بما في ذلك انتشار DNS. يمكنك متابعة تقدّمه من مساحة العميل الخاصة بك (سجلّ الخدمة المعنية)، ونبقيك على اطّلاع في كل مرحلة.

نعم، ندعم الترحيل من معظم مزوّدي الاستضافة، ولا سيما تلك التي تستخدم cPanel.

إنه مشمول في خطتَي Business و Pro. في الحالات الأخرى، تُقدَّم خدمة ترحيل مُساعَد كخيار إضافي.

نعم، يستلزم تغيير عنوان IP الإرسال مرحلة إحماء تدريجية: ابدأ بأحجام صغيرة (50 إلى 100 رسالة يومياً في الأسبوع الأول) لبناء سمعة IP الجديد تدريجياً. تأكّد من إعداد SPF وDKIM وDMARC بشكل صحيح منذ أول إرسال، ثم راقب تقارير DMARC لمدة 2 إلى 4 أسابيع للكشف عن أي مشكلة. فريق الدعم لدينا متاح على [email protected] لمساعدتك.

تمرّ عملية النقل بأربع مراحل: صدّر الصور والأحجام (`docker save` ثم `rsync` للبيانات)، وجهّز خادم ‎VPS‎ الهدف بتثبيت ‎Docker‎ وضبط متغيرات البيئة، ثم انقل البيانات وشغّل الحاويات، وأخيرًا حوّل ‎DNS‎ فقط بعد التحقق من صحة التشغيل على الخادم الجديد. للتطبيقات الحساسة لانقطاع الخدمة، أبقِ الخادم القديم نشطًا حتى اكتمال نشر ‎DNS‎. إذا احتجت إلى مساعدة، افتح تذكرة دعم من منطقة العميل.

يتضمن WHM أداة نقل مدمجة تُسمى Transfer Tool (من Packages > Transfer Tool)، تتيح لك ترحيل جميع حسابات cPanel من خادم WHM المصدر إلى خادمك الجديد في ServOrbit، بما في ذلك الملفات وقواعد بيانات MySQL والبريد الإلكتروني ومناطق DNS. تُدخل عنوان IP أو اسم المضيف لخادم WHM المصدر وبيانات الوصول أو رمز API، ثم تختار الحسابات المراد نقلها. تعتمد مدة النقل على حجم البيانات الإجمالي، وقد تتراوح بين 30 دقيقة وعدة ساعات لموزعي البيانات الكبار. يُنصح بإبقاء DNS يشير إلى الخادم القديم أثناء النقل، ثم تحويله بعد التحقق من اكتمال العملية لتقليل وقت التوقف.

صدِّر قاعدة بياناتك باستخدام `pg_dump`، ثم انقل الملف عبر `rsync` أو `scp` إلى خادم ‏VPS الخاص بك على ServOrbit، ثم استعدها بواسطة `pg_restore` أو `psql`. تحقّق من إصدارات PostgreSQL قبل النقل لتفادي أي تعارض، واختبر اتصال التطبيق قبل تحويل ‏DNS. يمكن لفريق الدعم مساعدتك إن واجهتَ أي عائق.

نعم. هذه الحلول هي تطبيقات قياسية تُثبَّت على أي خادم ‏VPS يعمل بنظام لينكس. انسخ بياناتك احتياطيًّا (المستودعات والإعدادات وقاعدة البيانات)، انقلها إلى خادم ‏ServOrbit VPS، ثم أعد تشغيل التطبيق — العملية مطابقة لأي نقل خادم تقليدي. يوفّر مدوّنتنا أدلة مفصّلة خطوة بخطوة للحلول الرئيسية.

قبل الترحيل، صدّر جميع سيناريوهاتك (Workflows) من واجهة n8n عبر (Settings → Import/Export) ودوّن متغيرات البيئة الخاصة بك (مفتاح التشفير وبيانات اعتماد قاعدة البيانات). أوقف عملية npm، ثم ثبّت Docker وDocker Compose على VPS الخاص بك، واستخدم وصفة n8n Docker الرسمية مع تحميل نفس مجلد البيانات (~/‎.n8n) داخل حجم الحاوية للحفاظ على سيناريوهاتك وبياناتك. يوصي فريق n8n بالانتقال إلى Docker قبل الإصدار v3.0 الذي سيتوقف عن دعم التثبيت العام عبر npm؛ ويمكن لفريق الدعم مساعدتك عبر [email protected].

نعم، يُدخل ‎Docker v29 عدة تغييرات جذرية ينبغي أخذها بعين الاعتبار: تطور شبكة bridge الافتراضية، وحُذفت بعض خيارات `docker run` التي تم إهمالها منذ ‎v24، كما تغيّر تنسيق مانيفيست multi-arch. قبل الانتقال، راجع ملفات `docker-compose.yml` والـ Dockerfiles بحثاً عن الخيارات المتقادمة، واختبر في بيئة تأهيلية، ثم انتقل. يُفصّل مقالنا حول الانتقال إلى ‎Docker v29 خطوات التحقق.

تتضمن العملية حفظ سير عمل LangFlow (تصدير JSON من الواجهة) ونماذج Ollama (مجلد `~/‎.ollama/models`)، ثم نقلها إلى الخادم الجديد عبر `rsync` أو `scp`. بعد إعادة تثبيت الخدمات على الخادم الجديد، أعد استيراد سير العمل وتحقق من متغيرات البيئة (مفاتيح API والروابط). خطط لنافذة صيانة قصيرة عند تبديل DNS لتجنب أي انقطاع.

تتبع عملية الترحيل من ‎Oracle Cloud إلى خادم ‎VPS في ‎ServOrbit خطوات واضحة: صدِّر صور ‎Docker باستخدام `docker save`، وانقلها عبر ‎SSH أو سجل خاص، ثم أعد إنشاء خدماتك باستخدام ملفات `docker-compose.yml` الحالية. للبيانات الدائمة، انسخ الأحجام باستخدام `rsync` أو `docker cp`. يُنصح باختبار الإعداد على الخادم الجديد قبل تحويل ‎DNS، مع إبقاء ‎TTL قصيرًا (300 ثانية) لتقليل نافذة التبديل. تعمل خوادم ‎VPS في ‎ServOrbit بنظامَي ‎Debian أو ‎Ubuntu وهي متوافقة مع جميع صور ‎Docker القياسية. يتوفر وصول ‎SSH بصلاحيات ‎root فور تفعيل الخادم.

نعم، يتضمن ‎Mattermost أداة استيراد أصلية متوافقة مع تنسيق تصدير ‎Slack. تتضمن العملية تصدير بياناتك من ‎Slack (ملف ‎ZIP يُوفَّر عبر واجهة الإدارة)، ثم تحويلها واستيرادها باستخدام الأمر `mattermost import slack` أو أداة `mmetl`. تُستعاد الرسائل والقنوات العامة والمرفقات بشكل عام. قد تستلزم الرسائل المباشرة وبعض الرموز التعبيرية المخصصة معالجةً إضافية وفق إصدارك. يُنصح بإجراء استيراد تجريبي على نسخة نظيفة قبل التبديل النهائي. تتم العملية بالكامل على خادم ‎VPS في ‎ServOrbit دون الاعتماد على أي خدمة خارجية.

يتضمّن ‎OpenProject أداة ‎Jira Migrator رسمية متاحة منذ الإصدار 17.4 (نسخة بيتا أُصدرت في مايو 2026). تنقل المشاريع و‎issues (العنوان والوصف والمرفقات وتاريخ الاستحقاق والساعات المقدّرة)، ومعرّفات ‎issues، والحقول المخصّصة البسيطة (نص، أرقام، تواريخ، قوائم منسدلة)، والمستخدمين والحالات والأنواع والتعليقات. ما لا يُنقل: العلاقات بين ‎issues، والتعيينات للسبرينت، وسير العمل الآلي والصلاحيات المعقّدة. الإجراء: من نسختك في ‎Jira، صدِّر ملف ‎XML كاملاً (‎Administration → ‎System → ‎Backup). في ‎OpenProject، اذهب إلى ‎Administration → ‎Import → ‎Jira وحمِّل ملف ‎XML. تعتمد مدة النقل على الحجم — خصّص 15 إلى 30 دقيقة لأقل من 10,000 ‎issue.

توفّر ‎Gitea‎ أداة هجرة مدمجة (الإدارة ← المستودعات ← هجرة) تستورد مستودع ‎GitHub‎ عبر عنوان ‎URL‎ مع الحفاظ الكامل على سجل ‎commit‎ والفروع والعلامات باستخدام ‏`git clone --mirror`‏. لنقل عدة مستودعات، استخدم ‎Gitea API‎ مع سكريبت يكرر العملية على كل مستودع. بعد الانتهاء، حدّث ‎remotes‎ المحلية بالأمر ‏`git remote set-url origin <url-جديد>`‏. راجع صفحة ‏`/vps-cloud`‏ لنشر نسخة ‎Gitea‎ على خادم ‎VPS ServOrbit‎.

تتضمن ‎Gitea‎ هجرة أصلية لـ‏‎issues‎‏ و‎milestones‎ من ‎GitHub‎: عند إنشاء المستودع أو تحديثه عبر أداة الهجرة (أو ‎API‎ ‏`POST /api/v1/repos/migrate`‏)، فعّل خيارات ‏`issues`‏ و‏`milestones`‏ و‏`labels`‏. يُطلب رمز وصول شخصي من ‎GitHub‎ بصلاحية ‏`repo`‏ لتجاوز حدود الاستخدام والوصول إلى المستودعات الخاصة. تُستورد كذلك التعليقات والمُعيَّنون والتسميات. لمجموعات ‎issues‎ الكبيرة، خصّص وقتًا كافيًا يتناسب مع الحجم إذ تلتزم ‎Gitea‎ بحدود ‎API GitHub‎.

نعم، عبر استيراد ‎CSV الأصيل في ‎Plane: في ‎Linear، صدِّر مشكلاتك بتنسيق ‎CSV (Settings → Export)، ثم في نسخة ‎Plane الخاصة بك اذهب إلى الإعدادات → المستوردون → ‎CSV وارفع الملف. يُستورد العناوين والأوصاف والأولويات والتسميات؛ أما التعليقات فلا يشملها تنسيق ‎CSV الخاص بـ‎Linear — يحتاج الحفاظ عليها إلى تصدير ‎JSON كامل عبر ‎API ‏‎Linear. للحصول على ترحيل كامل يشمل سجل التعليقات، يمكن لفريق الدعم مساعدتك؛ تواصل معنا عبر لوحة العملاء.

يبلغ Confluence Data Center نهاية دعمه في 28 مارس 2029 ويتحول إلى وضع القراءة فقط. Docmost بديل مفتوح المصدر يدعم المساحات والأذونات والتحرير التشاركي؛ أداة الاستيراد الأصلية (إصدار Enterprise) تحافظ على هيكل المساحات والمرفقات والروابط ومخططات draw.io. تتم الهجرة بتصدير المساحات بصيغة XML من Confluence ثم استيرادها في Docmost. بدون إصدار Enterprise، الهجرة يدوية. اطلب خادم VPS من ServOrbit بذاكرة 2 غيغابايت على الأقل وانشر Docmost من المتجر.

Planka v2.2.0 (9 أغسطس 2026) نقل SSO OIDC إلى Planka Pro المدفوع. لا يوجد تصدير JSON أو CSV أصلي (issues #22 و#670 غير محلولة) — الاستخراج الموثوق عبر `pg_dump`. للهجرة: (1) لقطة كاملة للقاعدة، (2) تشغيل مزدوج لأسبوع، (3) نقل يدوي للبيانات، (4) تحويل DNS واحتفظ بالنسخة 90 يومًا. Kaneo وVikunja يحتفظان بـ SSO OIDC مجانًا ومتاحان في متجر ServOrbit.

يزيل تحديث ‏Immich من ‏v2 إلى ‏v3 الإضافة ‏pgvecto.rs ويستبدلها بـ‏pgvector الأصلي. قبل التحديث (بدءًا من ‏v1.132.3)، احتط لحجم ‏PostgreSQL بأكمله بأمر: `docker compose exec database pg_dumpall -U postgres > backup.sql`. حدِّث ملف `docker-compose.yml` نحو الصورة `ghcr.io/immich-app/immich-server:v1.132.3`، ثم نفِّذ `docker compose pull && docker compose up -d`: تُجرى ترقية المخطط تلقائيًا عند الإقلاع. صورك وألبوماتك ومشاركاتك غير متأثرة — تواصل مع [email protected] إذا فشلت الترقية عند البدء.

يقبل ‎Passbolt CE استيراد ‎CSV و‎JSON (من الإدارة > Import passwords). من ‎Bitwarden: صدِّر بصيغة ‎CSV غير مشفّر. من ‎1Password: صدِّر بصيغة ‎1PUX ثم كيِّف الأعمدة وفق التنسيق المطلوب. تُعاد كتابة كلمات المرور المستوردة بمفاتيح ‎GPG للمستلمين المحددين.

أنهى ‎Forgejo v16 التوافق المباشر مع ‎Gitea: أتمّ الفريق الانتقال إلى مخطط قاعدة بيانات مسارات ضبط مستقلة. للانتقال من ‎Gitea، يُوصى أولًا بالانتقال إلى ‎Forgejo v7 أو v8 (آخر إصدار مُهيَّأ لاستيراد ‎Gitea)، وتشغيل ترحيلات المخطط، ثم الترقية تدريجيًا حتى v16. يبقى استخدام ‎`gitea dump` متبوعًا باستعادة `forgejo admin` الأسلوبَ الأنظف للنسخ متوسطة الحجم. افتح تذكرة من فضاء عميلك إذا احتجت إلى مساعدة في تنفيذ العملية على خادم ‎VPS من ‎ServOrbit.

استبدل ‎Supabase كلًّا من ‎Kong بـ‎Envoy Gateway بوصفه وكيلًا داخليًا اعتبارًا من أغسطس 2026: تختلف متغيرات بيئة التوجيه ومهلات الانتظار وضبط الإضافات اختلافًا ملحوظًا. قبل سحب التحديث (`docker compose pull`)، راجع تخصيصاتك في `docker-compose.override.yml` (مسارات ‎Kong، وإضافات تحديد المعدل، و‎CORS)، واطّلع على ملاحظات الإصدار الرسمية للمكافئات في ‎Envoy، والتقط لقطة من أحجام ‎Docker. اختبر التحديث على خادم ‎VPS مرحلي قبل تطبيقه في الإنتاج، وتحقق من سجلات ‎Envoy عند بدء التشغيل الأول لرصد أي مسارات لم تُرحَّل.

ثبِّت الثنائي Forgejo Runner على خادمك، وسجِّله بالرمز المولَّد في إعدادات Forgejo (الإعدادات → الإجراءات → المشغِّلات)، ثم أنشئ مهام سير العمل في `.forgejo/workflows/` بنفس صياغة YAML المستخدمة في GitHub Actions. معظم الخطوات متوافقة؛ يكفي استبدال تصنيف `ubuntu-latest` بتصنيف مشغِّلك (`self-hosted`). لأي استفسار حول التحجيم أو الإعداد، افتح تذكرة من فضائك العميل.

تكاد توقف قصير (بضع دقائق) يكون حتميًا خلال ترقية Chatwoot الرئيسية، نظرًا لأن هجرات قاعدة البيانات تعمل في وضع الحجب. للتقليل من الأثر: انسخ PostgreSQL والأحجام نسخًا احتياطيًا كاملًا، واختبر الترقية على بيئة تجريبية، ثم جدوِّل التبديل خارج ساعات الذروة. تبقى قناة إشعارات Chatwoot متاحة للوكلاء خلال نافذة الصيانة إذا نشرت رسالة حالة مسبقًا. للاستعانة بخبرائنا في التخطيط، افتح تذكرة من فضائك العميل.

يمكن الترحيل دون توقف باتباع هذه الإجراءات: **الخطوة 1: نسخ احتياطي من المضيف القديم** - تصدير قاعدة بيانات MySQL عبر phpMyAdmin أو `mysqldump` - أرشفة ملفات WordPress (خاصة مجلد `wp-content/`) **الخطوة 2: إنشاء البيئة على ServOrbit** - إنشاء VPS مع Debian/Ubuntu وتثبيت WordPress - استعادة قاعدة البيانات والملفات - إعداد `wp-config.php` بمعلومات الاتصال الجديدة **الخطوة 3: الاختبار قبل التحويل** - الوصول إلى الموقع الجديد عبر عنوان IP (أو إدخال في `/etc/hosts`) قبل تغيير DNS **الخطوة 4: تقليل TTL لـ DNS** - قبل 24–48 ساعة من الترحيل، قلّل TTL لـ DNS إلى 300 ثانية **الخطوة 5: تحويل DNS** - غيّر سجل A/AAAA إلى عنوان IP الجديد - ينتشر التغيير خلال 5 إلى 30 دقيقة مع TTL منخفض

نعم، نقل اسم النطاق لا يوقف موقعك إذا اتّبعت الإجراء الصحيح. **المبدأ الأساسي**: DNS وregistrar شيئان منفصلان. موقعك يعمل طالما تجيب خوادم DNS بشكل صحيح — بغض النظر عمّن يمتلك registrar. **إجراء بدون انقطاع:** 1. **قبل بدء النقل**: تحقق من أن DNS مُدار لدى مزوّد مستقر (Cloudflare، مضيفك الحالي) — ليس مباشرةً لدى registrar الأصلي. 2. **افتح قفل النطاق** لدى المسجّل القديم واحصل على رمز EPP/Auth. 3. **أطلق النقل** لدى ServOrbit. 4. **خلال النقل** (5–7 أيام لـ ‎.com، ‎.net؛ 2–3 أيام لـ ‎.fr؛ حتى 7 أيام لـ ‎.ma)، موقعك يستمر في العمل — DNS لا يتحرك. 5. **بعد النقل**: إذا كان DNS مُداراً لدى المسجّل القديم، ستحتاج إلى إعادة تكوينه لدى الجديد. خطّط لهذه الخطوة مسبقاً.

في Notion، اذهب إلى الإعدادات ← مساحة العمل ← تصدير المحتوى واختر صيغة Markdown وCSV للحصول على أرشيف صفحاتك وقواعد بياناتك. يُستخدم هذا الأرشيف نقطةَ انطلاق للاستيراد في Docmost أو AppFlowy. للمساحات الكبيرة، انتظر بضع دقائق حتى يُرسل Notion رابط التنزيل. إن احتجت مساعدة، تواصل معنا على [email protected].

تتيح Plane استيرادًا أصليًّا من Jira: في نسخة Plane، اذهب إلى الإعدادات ← المستوردون ← Jira، أدخل رابط Jira وtoken API، ثم اختر المشاريع للاستيراد — تُنقل المهام والإسنادات والتسميات والحالات. لـ Jira Data Center (غير السحابي)، قد يتطلب الموصّل وصولًا شبكيًّا مباشرًا؛ اختبر على مشروع صغير قبل الترحيل الكامل.

الطريقة الأكثر أماناً هي التصدير ثم الاستيراد: أوقف تشغيل تطبيقاتك، صدّر قواعد البيانات باستخدام الأمر `docker exec <pg15> pg_dumpall -U postgres > dump.sql`، ثم شغّل حاوية PostgreSQL 17 جديدة، واستورد الملف المُصدَّر وتحقق من كل قاعدة باستخدام `pg_dump --schema-only` قبل حذف الحاوية القديمة. خادم VPS من ‎ServOrbit‎ مع صلاحية root الكاملة يتيح لك تشغيل الحاويتين معاً خلال مرحلة التحقق. راجع صفحة ‎`/vps-cloud` لاختيار الإعداد المناسب لحجم قواعد بياناتك.

نعم، تقدم ServOrbit خدمة نقل من M365 إلى Nextcloud تشمل البريد الإلكتروني (IMAP إلى IMAP) والتقاويم (CalDAV) وجهات الاتصال (CardDAV). يُنجز النقل بأسلوب cutover أو delta وفق حجم الصناديق البريدية، دون انقطاع ملحوظ في الخدمة لمستخدميك. يمكن الإبقاء مؤقتاً على تراخيص M365 بالتوازي أثناء التحقق من النقل، ثم إلغاؤها وفق وتيرتك. تواصل مع فريق الدعم للحصول على تدقيق مسبق وعرض سعر مناسب لحجم مؤسستك.

يقوم الانتقال من Sentry إلى GlitchTip على تغيير بسيط لقيمة DSN (Data Source Name) في كل تطبيق: يوفر GlitchTip واجهة برمجية متوافقة مع Sentry، فيكفي توجيه متغير البيئة `SENTRY_DSN` إلى DSN الجديد الخاص بـ GlitchTip دون تعديل SDK أو الكود. يجب إعادة إنشاء قواعد التنبيه والفرق والمشاريع يدوياً في GlitchTip لعدم وجود تصدير تلقائي بين المنصتين. نوصي بمرحلة إرسال مزدوج (الإبقاء على Sentry نشطاً بالتوازي بضعة أيام) للتحقق من أن GlitchTip يرصد جميع الأخطاء قبل القطع النهائي.

‏صدِّر جهات الاتصال من ‏HubSpot عبر ‏Settings > Data Management > Export > Contacts بصيغة ‏CSV. في ‏Twenty CRM، استخدم ‏People > Import > CSV لرفع الملف؛ تُعيَّن الحقول الأساسية (الاسم الأول، اللقب، البريد، الهاتف) تلقائياً. أما خصائص ‏HubSpot المخصصة فيجب إعادة إنشائها يدوياً في ‏Twenty قبل الاستيراد.

يتضمن ‎Stalwart أداة ترحيل وبروكسي ترحيل يعملان معاً لنقل الحسابات بشكل مستمر: يواصل المستخدمون إرسال رسائل البريد واستقبالها طوال عملية النقل، حساباً تلو الآخر. عملياً، وجّه البروكسي إلى الخادم القديم بينما تنسخ الأداة رسائل البريد والمجلدات وفلاتر ‎Sieve ودفاتر العناوين والتقويمات؛ وبمجرد ترحيل حساب، يُعيد البروكسي توجيهه مباشرةً إلى ‎Stalwart. قبل تحويل ‎DNS، تحقق من سجلات ‎SPF و‎DKIM و‎DMARC على الخادم الجديد. يمكن لفريقنا مساعدتك عبر تذكرة من فضائك الخاص.

قبل أي ترحيل، صدِّر بياناتك بصيغ مفتوحة: CSV أو JSON لقواعد البيانات، وPDF للوثائق، وZIP للوسائط. تحقّق من اكتمال التصدير — بعض خدمات SaaS لا تُدرج المرفقات أو السجلّ التاريخي. احتفظ بنسخة خارج الخدمة (تخزين محلي أو سحابي كائني) قبل الإلغاء: بمجرد إغلاق الحساب تصبح البيانات في غير متناول. اختبر الاستيراد في الحل المستهدَف قبل قطع الوصول القديم، لتفادي أي فقدان للبيانات يمرّ دون أن يُكتشف.

ابدأ بمراجعة خدماتك الحالية: أحصِ ما تدفعه والبيانات المرتبطة بالتكاملات الحيوية. ثم اختر بديلًا مفتوح المصدر واختبره على خادم VPS للتطوير قبل أي تحويل. خطِّط للترحيل خارج أوقات الذروة، وأعِدّ خطة للتراجع وصدِّر بياناتك مسبقًا. انقل خدمة تلو أخرى بدلًا من الكل دفعة واحدة: هذا يحدّ من المخاطر ويُيسّر التشخيص عند حدوث مشكلة. تحقّق من أن النسخ الاحتياطية التلقائية تعمل قبل إلغاء اشتراكاتك القديمة.

قبل أي نقل، أجرِ نسخاً احتياطياً كاملاً باستخدام الأمر `bench backup` من ‎Frappe‎، وهو يُصدِّر قاعدة البيانات والملفات في أرشيف واحد. على ‎VPS ServOrbit‎ الجديد، ثبِّت ‎ERPNext‎ عبر قالب سوق التطبيقات أو يدوياً، ثم استورد النسخة الاحتياطية بالأمر `bench restore` وحدِّث عنوان الموقع في ملف `currentsite.txt`. تحقق من صلاحيات الملفات واختبر الوصول قبل تحويل ‎DNS‎ لتفادي أي انقطاع. يمكن لفريقنا مساعدتك في هذه المهمة عبر تذكرة دعم.

‎استخدم واجهة ‎‎API‎ الخاصة بـ‎‎GitLab‎ (‎‎`/api/v4/projects?owned=true`‎) لسرد مستودعاتك، ثم انسخها بالأمر `git clone --mirror`. يتضمن ‎‎Gitea‎ معالج استيراد مدمجاً (الإدارة ← الترحيل) يقبل رابط ‎‎GitLab‎ وينشئ تلقائياً المستودعات والمشكلات وطلبات السحب. بالنسبة للفضاءات ذات الأسماء للقراءة فقط أو المجموعات، قم أولاً بتصدير أرشيف ‎‎tarball‎ من ‎‎GitLab‎ (الإعدادات ← عام ← تصدير المشروع)، ثم استورده إلى ‎‎Gitea‎ عبر الواجهة أو واجهة ‎‎API‎ الخاصة بها. خطط لتوفير ذاكرة وصول عشوائي لا تقل عن 2 جيجابايت على خادمك لضمان عملية نقل سلسة.