قائمة نقل التطبيقات: 20 نقطة تحقق أساسية

لماذا تحتاج قائمة تحقق للترحيل؟

ترحيل تطبيق من سيرفر لآخر يشمل عشرات التفاصيل الصغيرة. نسيان واحدة منها قد يعني تطبيق معطّل أو بيانات مفقودة. القائمة التالية تغطي كل جانب من جوانب الترحيل، من البنية التحتية إلى DNS، لتضمن إنك ما تنسى شيء.

اطبعها، ضع علامة على كل بند، ولا تبدأ التحويل حتى تكتمل كل الخطوات.

المرحلة 1: قبل الترحيل (قبل أسبوع على الأقل)

البنية التحتية

• تأكد إن السيرفر الجديد جاهز بالمواصفات المطلوبة (CPU، RAM، SSD)
• نظام التشغيل مثبّت ومحدّث بآخر تحديثات الأمان
• الجدار الناري مُعَد بنفس قواعد السيرفر القديم
• Fail2ban أو أداة حماية مشابهة مُفعّلة
• SSH مُعَد (مفاتيح بدل كلمات مرور، منفذ مخصص)
• المنطقة الزمنية صحيحة (Asia/Riyadh)
• NTP مُفعّل لمزامنة الوقت

البرمجيات

• نفس إصدار لغة البرمجة (PHP 8.3، Python 3.12، Node 20، إلخ)
• نفس إصدار قاعدة البيانات (MySQL 8.0، PostgreSQL 16، إلخ)
• نفس إصدار خادم الويب (Nginx 1.24، Apache 2.4، إلخ)
• جميع الإضافات والمكتبات المطلوبة مثبتة
• Composer / npm / pip dependencies مثبتة
• Redis أو Memcached إن كان التطبيق يستخدمهم
• إعدادات PHP (php.ini): memory_limit، upload_max_filesize، max_execution_time

التطبيق

• الكود مرفوع للسيرفر الجديد (عبر Git أو rsync)
• ملف الإعدادات (.env) محدّث بمعلومات السيرفر الجديد
• مجلدات التخزين (storage/uploads) لها الصلاحيات الصحيحة
• مجلد الـ cache فارغ وقابل للكتابة
• مجلد الـ logs فارغ وقابل للكتابة

المرحلة 2: البيانات

قاعدة البيانات

• نسخة احتياطية كاملة من قاعدة البيانات القديمة
• استيراد البيانات في السيرفر الجديد
• مقارنة عدد الصفوف في الجداول الرئيسية
• اختبار الاستعلامات الحرجة
• التحقق من الـ Indexes والـ Foreign Keys
• التحقق من Stored Procedures والـ Views
• تعيين صلاحيات المستخدمين

الملفات

• نقل جميع ملفات المستخدمين (uploads, media, documents)
• التحقق من عدد الملفات وأحجامها
• التحقق من صلاحيات الملفات والمجلدات
• نقل الملفات المؤقتة إن لزم الأمر

المرحلة 3: الخدمات والتكاملات

خدمات النظام

• Cron Jobs: نسخ جميع المهام المجدولة
• Supervisor: إعداد عمليات الخلفية (Queue Workers, WebSocket)
• Logrotate: إعداد أرشفة السجلات
• النسخ الاحتياطي التلقائي مُعَد ومختبر

التكاملات الخارجية

• بوابات الدفع: تحديث عنوان IP المسموح (Whitelist)
• خدمات الإشعارات: تحديث Webhook URLs إن لزم
• APIs خارجية: التحقق من إن مفاتيح API تعمل من السيرفر الجديد
• خدمات البريد: تحديث سجلات SPF و DKIM بعنوان IP الجديد
• CDN: تحديث عنوان Origin Server

المرحلة 4: الأمان

• شهادات SSL مثبتة وتعمل
• إعادة توجيه HTTP إلى HTTPS مُفعّلة
• Headers الأمان مُعَدة (HSTS, CSP, X-Frame-Options)
• كلمات المرور الافتراضية مُغيّرة
• الخدمات غير المستخدمة معطّلة
• المنافذ غير الضرورية مغلقة

المرحلة 5: DNS والتحويل

• خفض TTL قبل 48 ساعة من التحويل
• تحضير سجلات DNS الجديدة (A, AAAA, MX, CNAME, TXT)
• تحويل DNS في وقت أقل استخدام
• مراقبة انتشار DNS عبر أدوات مثل whatsmydns.net
• إبقاء السيرفر القديم يعمل 48 ساعة بعد التحويل

المرحلة 6: بعد التحويل

• اختبار جميع الصفحات الرئيسية
• اختبار تسجيل الدخول والصلاحيات
• اختبار رفع الملفات وتحميلها
• اختبار النماذج وإرسال البريد
• اختبار عمليات الدفع (في بيئة تجريبية)
• مراقبة السجلات لأي أخطاء
• التحقق من أداء التطبيق وأوقات الاستجابة
• إعلام الفريق بنجاح الترحيل

أخطاء شائعة في ترحيل التطبيقات

من واقع الخبرة، هذه أكثر الأخطاء تكراراً عند ترحيل التطبيقات:

• اختلاف إصدار PHP: التطبيق يعمل على PHP 8.1 في السيرفر القديم لكنك ثبّت PHP 8.3 في الجديد. بعض الدوال تغيّر سلوكها أو أُلغيت. الحل: تأكد من تطابق الإصدار أو اختبر التوافقية مسبقاً
• صلاحيات المجلدات: التطبيق يعمل لكن رفع الملفات يفشل لأن مجلد storage ما عنده صلاحيات كتابة. الحل: chown -R www-data:www-data storage
• ملف .env القديم: نسيت تحديث بيانات اتصال قاعدة البيانات أو مفاتيح API في ملف .env الجديد
• نسيان Queue Workers: التطبيق يعمل لكن الإشعارات والرسائل ما تُرسل لأن عمليات الـ Queue متوقفة
• اختلاف إعدادات PHP: memory_limit أو max_execution_time مختلفة عن السيرفر القديم
• عدم تفريغ الـ Cache: التطبيق يعرض بيانات قديمة لأن الـ Cache لم يُفرّغ بعد الترحيل

أتمتة الترحيل: هل تستحق؟

لو ترحّل تطبيق واحد مرة واحدة، الأتمتة غير ضرورية. لكن لو عندك عدة تطبيقات أو تتوقع ترحيلات مستقبلية، أتمتة العملية توفر وقتاً وتقلل الأخطاء:

• Ansible: اكتب Playbook يجهّز السيرفر الجديد بالكامل (نظام تشغيل، برمجيات، أمان)
• Shell Scripts: سكريبت واحد ينقل قاعدة البيانات والملفات ويتحقق من السلامة
• CI/CD Pipeline: لو تستخدم GitHub Actions أو GitLab CI، أضف مرحلة deploy تلقائية

الاستثمار في الأتمتة يعود عليك في كل ترحيل مستقبلي. عملية كانت تأخذ 8 ساعات يدوياً تصبح 30 دقيقة بضغطة زر.

الدعم الفني من كلاود

كلاود (cloud.net.sa) يوفر جلسات توجيه تقني مجانية لمطوّري العملاء أثناء الترحيل. لو عندك نظام مخصص (ERP أو CRM أو تطبيق داخلي)، فريقنا يساعد مطوّرك في التخطيط والتنفيذ. المطور يتولى العملية، ونحن نوفر الإرشاد الفني في كل مرحلة.

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

--- ### ابدأ الآن تبي تجرب بنفسك؟ اختر باقة الاستضافة المناسبة أو صمم سيرفرك الخاص بالمواصفات اللي تبيها.