الترحيل

نعم. مساعد الترحيل مشمول في جميع العروض بما فيها Start: ينقل نطاقاتك ويستعيد حسابات cPanel الخاصة بك في طلب واحد، دون انقطاع الخدمة. وابتداءً من Business، يكون تكفّل فريقنا بالترحيل من البداية إلى النهاية مشمولًا أيضًا.

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

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

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

تتوقف مدته على حجم الموقع وكمية البيانات. ويجري على ثلاث مراحل: النقل (النطاقات برمز EPP، وحساب cPanel المستعاد من نسخة احتياطية أو بالنقل المباشر)، ثم التحقق من الموقع على خوادمنا، ثم تحويل DNS — ويبقى موقعك متاحًا لدى مزوّدك الحالي حتى هذا التحويل. يمكنك متابعة تقدّمه من مساحة العميل الخاصة بك (سجلّ الخدمة المعنية)، ونبقيك على اطّلاع في كل مرحلة.

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

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

نعم، يستلزم تغيير عنوان 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. للحصول على ترحيل كامل يشمل سجل التعليقات، استخدم واجهة 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 جيجابايت على خادمك لضمان عملية نقل سلسة.

من ‎Kommo‎، صدِّر جهات الاتصال والشركات والصفقات بصيغة ‎CSV‎ عبر الإعدادات ← التصديرات. ثم استورِد هذه الملفات إلى ‎Twenty‎ من تبويب الاستيراد لكل كائن (‏People وCompanies وOpportunities). أما المرفقات وسجلّ المحادثات، فتحقّق من خيارات التصدير المتاحة في ‎Kommo‎ واحتفظ بها بشكل منفصل. فريقنا جاهز لمساعدتك في التخطيط للهجرة.

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

تتيح ‎ServOrbit ترحيلاً مساعداً يُنسخ خلاله موقعك وقاعدة بياناته إلى خوادمنا قبل أي تغيير في ‎DNS. بعد التحقق على الاستضافة الجديدة، يستغرق تحويل ‎DNS بضع دقائق فحسب، مما يحصر الانقطاع في وقت انتشار ‎TTL. تواصل مع ‎[email protected] لجدولة الترحيل.

لا نعلن عن مدة نموذجية: فهي تتوقف على حجم البيانات وعدد الحسابات المراد ترحيلها. أما المراحل فهي نفسها دائمًا: النقل (النطاقات برمز ‎EPP‎، وحسابات ‎cPanel‎ المستعادة من نسخة احتياطية أو بالنقل المباشر)، ثم التحقق على خوادمنا، ثم تحويل ‎DNS‎. لا يُمَسّ حساب الاستضافة المصدر: يبقى الموقع متاحًا لدى مزوّدك الحالي حتى التحويل. مساعد الترحيل مشمول في جميع العروض بما فيها ‎Start‎، وتكفّل فريقنا بالترحيل من البداية إلى النهاية مشمول ابتداءً من ‎Business‎. ولأي حالة خاصة، راسل ‎[email protected]‎.

الأسلوب الموصى به هو تصدير قاعدة البيانات عبر ‎mysqldump على الاستضافة القديمة، ثم استيرادها على ‎VPS بينما تظل الاستضافة القديمة نشطة، ثم تحويل إعدادات تطبيقك إلى الخادم الجديد بعد اختبار التناسق. يمكن ‎ServOrbit تنسيق هذه العملية نيابةً عنك؛ تواصل مع ‎[email protected] لجدولة الترحيل خارج ساعات الذروة.

نعم، يمكن نقل بريد شركتك الإلكتروني من الاستضافة المشتركة إلى خادم ‎VPS‎ من ‎ServOrbit‎. تشمل عملية الترحيل نقل صناديق البريد وجهات الاتصال وسجل الرسائل عبر بروتوكول ‎IMAP‎. نوصي باستخدام أداة مثل ‎imapsync‎ لتفادي أي فقدان للبيانات: تُجري الترحيل بنفسك، ويجيب الدعم عن أسئلتك. خطّط لفترة تحويل ‎DNS‎ مناسبة وأبقِ على إمكانية الوصول إلى الاستضافة القديمة لمدة 48 إلى 72 ساعة لضمان استمرارية الخدمة.

الانتقال من Odoo.sh أو الـ SaaS الرسمي إلى VPS مستضاف ذاتيًا ممكن تقنيًا، لكنه يتطلب عدة خطوات. أولًا، يجب تصدير نسخة احتياطية من قاعدة بيانات PostgreSQL ومجلد `filestore` من المنصة المصدر. على الـ VPS، يلزم تثبيت Odoo بنفس الإصدار الرئيسي قبل استيراد البيانات. يجب تحديد الوحدات المطورة خصيصًا للمنصة السحابية (تكاملات Odoo.sh، وحدات Enterprise المدفوعة غير المضمَّنة في Community) واستبدالها. أخيرًا، يجب إعادة تهيئة شهادات SSL وإعدادات DNS والوصول إلى SMTP على الخادم الجديد قبل تحويل حركة المرور.

تتم عملية النقل في ثلاث خطوات: صدِّر محتواك من ‎Squarespace (الأدوات ← التصدير)، استورده إلى ‎Ghost عبر لوحة الإدارة، ثم أشر نطاقك إلى خادم ‎VPS الخاص بك من ‎ServOrbit. يُثبَّت ‎Ghost في دقائق عبر السوق؛ احرص على توفير ذاكرة ‎RAM لا تقل عن ‎1 جيجابايت. لأي سؤال، افتح تذكرة من منطقة العميل مع تحديد جدولك الزمني.

نعم، تتم عملية نقل ‪Plex‬ أو ‪Jellyfin‬ إلى ‪VPS ServOrbit‬ في ثلاث خطوات: تصدير قاعدة البيانات ومجلد البيانات الوصفية من التثبيت الحالي، ثم نقلها عبر ‪rsync‬ أو ‪SCP‬ إلى الخادم الجديد، وأخيراً إعادة تثبيت الخادم مع الإشارة إلى نفس المسارات. تُحفظ البيانات الوصفية وقوائم التشغيل وتقدم المشاهدة طالما ظلت مسارات المكتبة متطابقة أو أُعيد تكوينها بشكل صحيح. تمنحك خطط ‪VPS‬ الجذرية لدينا حرية كاملة في هيكلة المجلدات. تواصل مع [email protected] لأي سؤال حول نقل البيانات.

يوفر ‎Plane‎ أداة استيراد أصلية لـ ‎Asana‎ يمكن الوصول إليها من إعدادات مساحة العمل (‎Settings → Importers → Asana‎). تستورد هذه الأداة المشاريع والمهام والمهام الفرعية والمُسنَدين ومواعيد الاستحقاق والتعليقات. يُحفظ سجل النشاط جزئياً: تُضمَّن التعليقات المؤرخة وتغييرات الحالة، لكن المرفقات الكبيرة قد تحتاج إلى نقل يدوي بحسب حجمها. قبل بدء الاستيراد، أنشئ رمز وصول شخصياً في ‎Asana‎ ومنح صلاحيات القراءة على مساحات العمل المعنية. لا تحذف عملية الترحيل أي شيء من جانب ‎Asana‎، مما يتيح لك تشغيل النظامين بالتوازي خلال مرحلة التحقق. بعد تثبيت ‎Plane‎ على خادم ‎ServOrbit VPS‎ الخاص بك (لا يُعرض بعدُ للطلب في ‎Marketplace‎)، تعمل أداة الاستيراد مباشرةً من واجهة الويب دون الحاجة إلى أوامر ‎CLI‎. للترحيلات الكبيرة (أكثر من 10000 مهمة)، شغّل الاستيراد خارج أوقات الذروة لتجنب انتهاء المهلة.

تسير العملية دائماً في ثلاث خطوات: تصدير بياناتك من منصة ‎SaaS‎ (لوحة التحكم أو ‎API‎ حسب ما تتيحه)، ثم نشر التطبيق على خادم ‎ServOrbit‎ ‎VPS‎، ثم استيراد بياناتك. تتضمّن بعض التطبيقات أداة استيراد مدمجة؛ وفي غيرها يتمّ النقل عبر الملفات أو قاعدة البيانات. تتوفّر في ‎ServOrbit‎ قوالب ‎VPS‎ جاهزة للاستخدام على Marketplace لأكثر التطبيقات شيوعاً — يتضمّن القالب الإعداد الأوّلي والـ‎reverse proxy‎. افتح تذكرة من منطقتك إن احتجت مساعدة في عملية ترحيل محددة.

تتم الهجرة على عدة مراحل تُجريها بنفسك: صدِّر بريدك الإلكتروني عبر ‎Google Takeout‎ (بصيغة ‎MBOX‎)، ثم استورده إلى ‎Nextcloud Mail‎ أو ‎Roundcube‎ على خادم ‎VPS ServOrbit‎ الخاص بك. لملفات ‎Google Drive‎، ثبّت ‎Nextcloud‎ من متجر تطبيقات ‎ServOrbit‎ بنقرة واحدة، ثم استخدم أداة الهجرة المدمجة (‎rclone‎ أو موصل ‎Google Drive‎ في ‎Nextcloud‎).

الأسلوب الموصى به هو تجهيز البيئة على ‎ServOrbit‎ قبل تغيير ‎DNS‎: انسخ موقعك على الخادم الهدف، اختبره عبر ملف ‎hosts‎ المحلي، ثم اخفض قيمة ‎TTL‎ إلى 300 ثانية قبل 48 ساعة من الهجرة. بعد التحقق من النقل، حدّث إعدادات ‎DNS‎ لديك في ‎ServOrbit‎. يستغرق الانتشار عادةً أقل من 15 دقيقة بفضل بنيتنا مع ‎Cloudflare‎.

تتم هجرة Bitwarden Cloud إلى نسخة Vaultwarden مستضافة ذاتياً في ثلاث خطوات: صدِّر خزانتك من تطبيق Bitwarden (JSON غير مشفر أو مشفر)، ثم انشر Vaultwarden على VPS خاص بك لدى ServOrbit عبر Docker، ثم استورد الملف إلى نسختك الجديدة. Vaultwarden متوافق مع عميل Bitwarden الرسمي: لا حاجة لإعادة تثبيت التطبيق، فقط وجِّهه إلى نطاقك. يشرح مقالنا التفصيلي كل خطوة: الهجرة من Bitwarden Cloud إلى Vaultwarden على VPS.

تسير عملية نقل موقع التجارة الإلكترونية وفق الخطوات الكبرى نفسها للهجرة الاعتيادية، مع اهتمام خاص بقاعدة البيانات: صدِّر نسخة احتياطية كاملة (الملفات + تفريغ SQL) من مضيفك الحالي، ثم استوردها على استضافتك في ServOrbit، ثم اختبر موقعك بتعديل ملف hosts محليًا قبل أي تغيير في سجلات DNS — هكذا تبقى متجرك متاحًا لعملائك طوال العملية. بعد ذلك حدِّث إعدادات اتصال قاعدة البيانات في ملف إعداد تطبيقك (wp-config.php بالنسبة لـ WooCommerce، وparameters.php أو ‎.env بالنسبة لـ PrestaShop). بعد التحقق من الاختبارات، حدِّث سجلات DNS الخاصة بك؛ يستغرق النشر عمومًا أقل من 24 ساعة. يمكن لخدمة الهجرة المصحوبة لدينا تولّي العملية بأكملها — تواصل معنا عبر [email protected].

نعم، يمكنك نقل قاعدة البيانات فحسب (MySQL أو MariaDB أو PostgreSQL) إلى VPS من ServOrbit مع الإبقاء على موقعك لدى مزود الاستضافة الحالي، بشرط أن يدعم تطبيقك الاتصال بقاعدة بيانات بعيدة. ستحتاج إلى ضبط قواعد جدار الحماية ومستخدم MySQL للوصول عن بُعد وتحديث بيانات الاتصال في تطبيقك. يغطي مساعد الترحيل حسابات cPanel الكاملة المنقولة إلى الاستضافة؛ أما قاعدة بيانات منفردة نحو VPS فتنقلها بنفسك، ويجيب الدعم عن أسئلتك عبر تذكرة من منطقة العميل.

نعم، بشروط. يتيح ‎YNAB‎ تصدير المعاملات بصيغة ‎CSV‎ من تبويب «Reports». تقبل ‎Maybe.co‎ (المعروفة سابقاً بـ‎Maybe Finance‎) استيراد ‎CSV‎ للمعاملات. تحتفظ العملية بالمبالغ والتواريخ والفئات، لكن قواعد ميزانية ‎YNAB‎ (المظاريف) لا تنتقل تلقائياً — ستحتاج إلى إعادة إنشائها يدوياً في ‎Maybe‎. أجرِ أولاً اختباراً على تصدير جزئي قبل ترحيل كامل تاريخك.

توفّر ‌Atlassian‌ أداة ترحيل رسمية من السحابة إلى الخادم (أو مركز البيانات) يمكن الوصول إليها من واجهة إدارة نسختك السحابية؛ تُصدّر المشاريع والمشكلات والمساحات والسجلّ في أرشيف قابل للاستيراد على ‌VPS‌ الجديد. قبل بدء الترحيل، أعدّ ‌VPS‌ بذاكرة وصول عشوائي لا تقل عن 4 جيجابايت، ثبّت نفس الإصدار الرئيسي من ‌Jira‌ أو ‌Confluence‌، وتأكد من إمكانية الوصول إلى الخادم عبر ‌HTTPS‌ بشهادة ‌TLS‌ صالحة. يجيب فريق الدعم عن أسئلتك على [email protected] حول خطوات الاستيراد وإعداد ‌DNS‌.

يعتمد ترتيبك في ‏Google‎.ma‏ على الاستهداف الجغرافي المُعلَن في ‏Google Search Console‏، لا على الموقع الجغرافي للخادم. قبل النقل، حدد المغرب هدفاً جغرافياً في ‏Search Console‏، وتأكد أن نطاق ‎.ma لا يزال هو الرابط الأساسي، وضع تحويلات ‏301‏ إن تغيرت أي روابط. تنقل ملفاتك وقواعد بياناتك إلى ‏VPS‏ بنفسك، ويجيب الدعم عن أسئلتك؛ أما المساعد الموضَّح في صفحة الترحيل فيخص استضافة cPanel.

تعتمد الهجرة دون توقف على ثلاث مراحل: أولاً تفريغ منطقي أولي بـ‎pg_dump‎ ثم استعادته على الـ‎VPS‎، ثم إعداد النسخ المنطقي (‎replication slot‎ في ‎PostgreSQL‎ إصدار 10 أو أحدث) لتتبع الكتابات الجارية، وأخيراً تحويل سلسلة اتصال التطبيق خلال نافذة مجدولة قصيرة. يُوصى باختبار الاستعادة والأداء على ‎VPS ServOrbit‎ قبل التحويل، والإبقاء على نسخة ‎RDS‎ نشطة للقراءة فقط لساعات قليلة بعد الهجرة للتمكن من التراجع السريع عند الحاجة. راجع المقال المخصص في قاعدة المعرفة أو افتح تذكرة على ‎[email protected]‎ للحصول على مساعدة مخصصة.

نعم: تُصدَّر قائمة المشتركين، عادةً بصيغة CSV، من الأداة الحالية ثم تُستورد في الأداة الجديدة. صدِّر كذلك حالة كل جهة اتصال (مشترك، ملغٍ اشتراكه، عنوان فاشل) واستورد من ألغوا اشتراكهم بهذه الصفة، لا كمشتركين نشطين أبداً: فمراسلتهم من جديد تثير شكاوى تضرّ بسمعة نطاقك. وقبل أول إرسال من الخدمة الجديدة، أضف إلى منطقة DNS لنطاقك سجلَّي SPF وDKIM اللذين توفرهما، واحصر الإرسال الجماعي في هذه الخدمة بدلاً من بريدك المهني. وللمساعدة في هذه السجلات، افتح تذكرة من فضاء العميل.

يشمل تصدير المشروع الشيفرة والتذاكر وطلبات الدمج، لكنه لا يشمل متغيرات CI/CD ولا الـ webhooks ولا الرموز ولا ملفات المهام ولا صور سجل الحاويات. أعدّوا قائمة بهذه العناصر قبل التحويل وأعيدوا إنشاءها يدوياً على النسخة الجديدة، مع إبقاء المشروع القديم للقراءة فقط حتى اكتمال التحقق. توفّر ServOrbit دليلاً خطوة بخطوة لكنها لا تنفّذ الترحيل نيابةً عنكم.

أثناء انتشار DNS ما زال بعض الزوار يصلون إلى الخادم القديم، وكل ما يُرسلونه إليه لا يصل إلى الخادم الجديد. اخفض قيمة TTL مسبقًا، وأجرِ مزامنة أخيرة لقاعدة البيانات والملفات قبل التحويل مباشرة، ثم ضع الموقع القديم في وضع الصيانة أو عطّل الدفع والنماذج طوال مدة الانتقال. أبقِ الاستضافة القديمة فعّالة بعد ذلك، وتأكد من عدم وصول أي طلب أو تعليق إليها بعد المزامنة قبل إلغائها. وبالنسبة إلى المتجر، يمكن للترحيل المُساعَد أن يرافقك: راسلنا على [email protected].

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

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