الترحيل إلى السحابة

النداء الأخير للخوادم المحلية.
اليوم الأول في السحابة.

ننقل بنيتك التحتية من غرفة خوادم متقادمة إلى AWS أو GCP أو Azure أو إلى نموذج هجين على مراحل، وبأمان، مع جاهزية دائمة للتراجع (Rollback). لا نكتفي بنسخة افتراضية من أنظمتك، بل نقدّم فرص Cloud-Native حقيقية، وتكاليف مخفّضة بفضل انضباط FinOps، وخطة انتقال دون أي توقف.

من يقول «لننقل الأنظمة كما هي (Lift-and-Shift) لننتهي بسرعة» يجد فاتورته قد تضاعفت في الشهر السادس. الترتيب الصحيح: التقييم أولًا، ثم تصميم المعمارية، وأخيرًا الترحيل. ونحن لا نتجاوز هذا الترتيب أبدًا.

اطلب خطة الترحيل تعرّف على آلية العمل

ترحيل مباشر RUN-1

مركز بيانات محلي

نفقات رأسمالية مرتفعة

erp-svc

api-gw

postgres-db

queue-worker

analytics-job

السحابة

AWS GCP AZ

ec2 / gke

rds / aurora

s3 / gcs

eks / aks

نفقات تشغيلية مرنة

الاكتشاف

التقييم

التخطيط

التجربة

الترحيل

التحسين

التشغيل

دون أي توقف

لماذا تتعثر عمليات الترحيل الذاتية؟

الترحيل إلى السحابة ليس عملية «نسخ ولصق». فالترحيل الخاطئ يضخّم المشكلات ثم يرسل إليك فاتورتها.

بعد العام الأول، تكتشف 70% من الشركات التي نقلت خوادمها كما هي إلى أجهزة افتراضية وقالت «انتقلنا إلى السحابة» أن نفقاتها التشغيلية (OPEX) تفوق نفقاتها الرأسمالية (CAPEX) على الخوادم المحلية. والأسباب متعددة: فالنقل كما هو (Lift-and-Shift) لا يستفيد من فرص Cloud-Native، والتشغيل المتوازي الطويل يضاعف التكلفة، والاعتماديات غير المرصودة تسبّب انقطاعات متسلسلة، ولأن سياسات الأمان لا يمكن نسخها مباشرة تنشأ سطوح هجوم جديدة. كلها فخاخ معروفة مسبقًا، لكن من دون نهج منضبط تقع فيها الفرق واحدًا تلو الآخر.

النقل كما هو (Lift-and-Shift) لا يحقق أي وفر

نسخ جهاز افتراضي إلى السحابة يعني دفع ثمن خادم بالحجم نفسه كل شهر. وما لم تستخدم خدمات Cloud-Native (قواعد بيانات مدارة، وServerless، وتوسّع تلقائي)، فأنت تدفع الفاتورة القديمة بصيغة جديدة.

التشغيل المزدوج نزيف مستمر

إبقاء الخوادم المحلية والسحابة قيد التشغيل بالتوازي لأشهر يعني دفعتين وفريقي تشغيل. ومن دون خطة تمتد هذه المدة من 3 أشهر إلى 18 شهرًا، فتنفد الميزانية ويتأجل الانتقال.

اعتماديات غير مكتشفة

مهمة cron منسية في نظام قديم، أو مسار ملفات مشترك، أو عميل مرتبط بعنوان IP ثابت: بعد الترحيل تنكسر السلسلة. وإذا جرى تخطي مرحلة الاكتشاف (Discovery) انهارت الاعتماديات في بيئة الإنتاج.

سياسات الأمان لا تنتقل كما هي

يجب تحويل قواعد جدار الحماية المحلي إلى مزيج من IAM وKMS ومجموعات الأمان السحابية (Security Groups). أما النسخ المباشر فينتج عنه صلاحيات واسعة أكثر من اللازم وحماية ناقصة في الوقت نفسه.

حسابات خاطئة للشبكة وDNS

حركة البيانات بين مناطق التوفر (Cross-AZ)، وبوابات NAT، وربط VPC، والبيانات الصادرة (Egress): كلها بنود تبرز في الفاتورة. وإذا بُنيت المعمارية بشكل خاطئ بلغت الفاتورة الشهرية من 3 إلى 5 أضعاف المتوقع.

لا توجد خطة تراجع

إذا ظهرت مشكلة غير متوقعة يوم الانتقال، فبأي خطوة ستعود إلى الخوادم المحلية؟ من يقول «لا يمكننا» يخاطر كثيرًا، أما نحن فنُبقي طريق التراجع (Rollback) مفتوحًا في كل مرحلة.

لوحة مرئية للترحيل

متابعة شفافة: موقع كل حمل عمل، ومنحنى التكلفة، وقرار 6R المتخذ بشأنه.

لوحة Kanban: تدفق أحمال العمل

لكل حمل عمل بطاقته الخاصة.

الخوادم المحلية

REHOST
legacy-erp

RETAIN
tape-backup

قيد الترحيل

REPLATFORM
order-api

REHOST
billing-svc

REFACTOR
checkout-fn

جاهز للسحابة

DONE
auth-svc

DONE
cdn-edge

DONE
events-bus

التحول من CAPEX إلى OPEX

يتحول رأس المال المجمّد إلى عمليات متدفقة.

CAPEX

−68%

OPEX

+42%

الصافي

−31%

خريطة استراتيجيات 6R

نختار الاستراتيجية المناسبة لكل حمل عمل، ولا ننقل الأنظمة على غير هدى.

إعادة الاستضافة (Rehost)

النقل كما هو (Lift-and-Shift): الأسرع والأقل فائدة. قد تتحسن العملية، لكن التكلفة تبقى على حالها.

تغيير المنصة (Replatform)

النقل مع تعديلات طفيفة: قاعدة بيانات مدارة ونسخ احتياطي تلقائي. جهد متوسط ووفر حقيقي.

إعادة الهيكلة (Refactor)

إعادة الكتابة: Serverless، وخدمات مصغرة، ومعمارية قائمة على الأحداث. جهد كبير وأعلى وفر.

إعادة الشراء (Repurchase)

الانتقال إلى SaaS: استبدال البرمجيات القديمة المخصصة بخدمة SaaS قياسية. عملية قصيرة ونموذج مختلف.

الإيقاف (Retire)

تُغلق الخدمات القديمة التي لا يستخدمها أحد من دون ترحيلها.

الإبقاء (Retain)

الإبقاء على الخوادم المحلية: اللوائح، وزمن الاستجابة، والاستثمار في العتاد. فبعض الأنظمة لا تُنقل.

لمن هذه الخدمة؟

ثماني حالات نموذجية يصبح فيها قرار الانتقال إلى السحابة منطقيًا «الآن».

تجديد عتاد المؤسسات

خوادم عمرها من 5 إلى 7 سنوات، وضمان منتهٍ، وعرض تجديد على الطاولة. إنها اللحظة المنطقية لتحويل المبلغ نفسه إلى التزام سحابي لمدة 3 سنوات.

منتج SaaS تجاوز الاستضافة المشتركة (Colocation)

ازداد عدد العملاء وامتلأت الخزانات، وفتح موقع Colocation جديد خطأ في التوسع. الحل الصحيح هو سحابة متعددة المناطق.

تجارة إلكترونية بلغت حدود العتاد

تُرهق ذروات Black Friday والحملات التسويقية العتاد، ومن دون توسع تلقائي تخسر عملاءك.

توحيد الأنظمة بعد الاندماج والاستحواذ

شركتان، وثلاثة مراكز بيانات، وأربع حزم تقنية مختلفة. السحابة هي الأساس لتوحيدها في بنية تحتية مستهدفة واحدة.

القطاعات الخاضعة للتنظيم وموقع البيانات

قانون حماية البيانات الشخصية التركي رقم 6698 (KVKK)، والجهة التركية المنظمة للمصارف (BDDK)، والتمويل، والصحة: موقع البيانات وإمكانية تتبع التدقيق شرطان أساسيان. والسحابة تسهّل الامتثال عند اختيار المنطقة الصحيحة.

شركة ناشئة تجاوزت PaaS

تجاوزت حدود Heroku وRender وVercel وتحتاج إلى تحكم حقيقي في المعمارية. وتمنحك السحابة مع البنية التحتية ككود (IaC) مستوى احترافيًا.

تحديث القطاع العام والتعليم

الخوادم المحلية قديمة وميزانية الاستثمار محدودة، والمخرج الوحيد هو نموذج OPEX مع سعة مرنة.

التصنيع وبيانات إنترنت الأشياء (IoT)

تتطلب بيانات المستشعرات المتدفقة من المصنع معمارية متعددة الطبقات تجمع بين الحوسبة الطرفية (Edge) والسحابة. والخوادم المحلية وحدها لم تعد كافية.

10 تخصصات في فريق واحد

الترحيل والمعمارية وFinOps والأمان: الجميع في غرفة واحدة ودورة عمل (Sprint) واحدة.

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

الاكتشاف والتقييم

جرد تلقائي، ورسم خرائط الاعتماديات، وتحديد أنماط الاستخدام، وتصنيف كل حمل عمل ضمن الفئة المناسبة من فئات 6R الست.

نمذجة التكلفة الإجمالية للملكية (TCO) ودراسة الجدوى

تكلفة إجمالية للملكية على مدى 3 و5 سنوات، ومزيج من Reserved وSavings وSpot، ودراسة جدوى جاهزة للعرض على مجلس الإدارة.

تصميم المعمارية المستهدفة

معمارية Multi-AZ ومتعددة المناطق وفق مبادئ Well-Architected، مع تجاوز الفشل (Failover) والتعافي من الكوارث وأهداف RTO/RPO المحددة.

الترحيل التجريبي

حملا عمل منخفضا المخاطر لاكتساب المعرفة والثقة، ومرجع للموجات التالية.

ترحيل قواعد البيانات

قواعد PostgreSQL وMySQL وOracle وSQL Server وMongoDB: انتقال بأقل انقطاع ممكن.

الشبكة وVPN

شبكة VPN بين المواقع (Site-to-Site)، وDirect Connect/ExpressRoute، وربط VPC، ونظام DNS هجين.

مطابقة سياسات الأمان

من جدار الحماية المحلي وAD وGPO إلى IAM وSCP وKMS والتدقيق، دون فقدان أي صلاحية.

تحسين التكاليف (FinOps)

نماذج Showback/Chargeback، وضبط حجم الموارد (Right-Sizing)، والجدولة، وتخطيط RI/SP، وكشف الحالات الشاذة.

أدلة التشغيل (Runbooks) وتسليم العمليات

إجراءات التشغيل، ومجموعات التنبيهات، وتدريب فرق المناوبة، ونظام يُسلَّم إلى فريقك.

التحسين بعد الترحيل

ضبط التكلفة والأداء خلال أول 90 يومًا، ضمن دورة تحسين مستمر.

آلية العمل

من الاكتشاف إلى التشغيل المستقر: انتقال تدريجي في 6 خطوات.

01

الأسابيع 1-3 · الاكتشاف والتقييم

فحص تلقائي وورشة عمل ميدانية تغطي جميع أحمال العمل والاعتماديات وأنماط الاستخدام.
02

الأسابيع 3-6 · الخطة والتكلفة الإجمالية

المعمارية المستهدفة، وقرارات 6R، وخطة الموجات، والتكلفة الإجمالية للملكية (TCO) على مدى 3-5 سنوات، ومسار التراجع.
03

الأسابيع 6-10 · المرحلة التجريبية

حملا عمل منخفضا المخاطر، مع اختبار منطقة الهبوط (Landing Zone) وIaC والمراقبة ومسودات أدلة التشغيل.
04

الأسابيع 10-26 · موجات الترحيل

ترحيل على موجات مدة كل منها من أسبوعين إلى 3 أسابيع، وتنتهي كل موجة باختبار قبول مع جاهزية التراجع.
05

الأسابيع 26-32 · التحسين

ضبط حجم الموارد (Right-Sizing)، وشراء RI/SP، والجدولة التلقائية، وكشف الحالات الشاذة.
06

من الأسبوع 32 فصاعدًا · التشغيل والتسليم

أدلة التشغيل، والتنبيهات، والتدريب، والتسليم، مع تحسين مستمر ومراجعة FinOps شهرية.

الأدوات التي نستخدمها

أدوات الاكتشاف والترحيل والأتمتة وFinOps وفق معايير القطاع.

AWS Migration Hub Azure Migrate GCP Migration Center CloudEndure Carbonite Migrate Velostrata Terraform Ansible Datadog CloudHealth Apptio

قصص العملاء

قطاعات مختلفة، وانضباط واحد، ونتائج قابلة للقياس.

التصنيع مراكز البيانات: خفض 47%

شركة تصنيع متعددة المواقع

نُقل إلى AWS مركزا بيانات و180 خادمًا. وبعد 14 شهرًا انخفضت تكلفة مراكز البيانات بنسبة 47%، وأُلغيت ميزانية تجديد العتاد بالكامل.

SaaS 8 أسابيع

خدمة SaaS لقطاع الأعمال: 200 خدمة

رُحّلت 200 خدمة مصغرة إلى EKS خلال 8 أسابيع، وانخفض متوسط مدة النشر من 42 دقيقة إلى 6 دقائق.

التجارة الإلكترونية MTTR: خفض 73%

متجر إلكتروني عالي الحركة

سحابة متعددة المناطق مع تخزين مؤقت طرفي (Edge Cache)، وانخفاض MTTR من 4 ساعات إلى 65 دقيقة، ودون أي انقطاع في يوم الحملة.

التقنية المالية PCI ✓

منصة مدفوعات

منطقة هبوط (Landing Zone) متوافقة مع PCI-DSS ونموذج هجين، ودخلت المنصة مرحلة التدقيق مع الحفاظ على موقع البيانات.

الإعلام خفض 58% / 3 أضعاف

منصة نشر

تحويل ترميز الفيديو عبر مثيلات Spot وLambda، فانخفضت الفاتورة الشهرية بنسبة 58% وتضاعفت الإنتاجية 3 مرات.

اللوجستيات الوقت الفعلي

الشحن والتتبع

تتبع فوري عبر Kinesis وDynamoDB، وإيقاف نظام المعالجة الدفعية المحلي.

الأسئلة الشائعة

أكثر 8 أسئلة يطرحها العملاء

لا توجد إجابة واحدة صحيحة، فنحن نقرر لكل حمل عمل على حدة. إذا كان هدفك إغلاق مركز بيانات بسرعة ولن تستفيد الخدمة كثيرًا من مزايا Cloud-Native (مثل أداة داخلية نادرة الاستخدام)، فالنقل كما هو خيار منطقي. أما المكونات الحرجة في المنتج (واجهات API عالية الحركة، وقاعدة البيانات الرئيسية، وبنية قوائم الانتظار) فإن تغيير المنصة (Replatform) أو إعادة الهيكلة يخفّض التكلفة بنسبة 30-60% منذ العام الأول. النهج الصحيح هو تصنيف كل حمل عمل بتحليل 6R، ثم تنفيذ موجات مختلطة. والاستراتيجية الهجينة أكثر واقعية دائمًا من الاستراتيجية الخالصة. كما نتجنب عمليات الترحيل القائمة على مبدأ «كل شيء أو لا شيء»، فالنقل مع التحسين على مراحل يحمي الجدول الزمني والميزانية.

تمتلك AWS أوسع كتالوج خدمات وأكثر المنظومات انتشارًا، وهي في معظم الحالات خيار أولي آمن. وتبرز GCP في أحمال البيانات وتعلم الآلة وفي Kubernetes (GKE)، وتقدّم معمارية شبكية أنظف. أما Azure فتفضّلها المؤسسات المرتبطة بمنظومة Microsoft (AD و.NET وSQL Server وM365) لتكاملها الوثيق معها. ولا تُعد السحابة المتعددة شرطًا، بل تضيف تعقيدًا لا داعي له. لذلك نوصي بالبدء بطبقات مستقلة عن مزود السحابة (Kubernetes وTerraform)، فتبقى لديك مرونة النقل لاحقًا. ويحدد الاختيار خبرة فريقك، والسوق المستهدفة، واللوائح التنظيمية، والاتفاقيات القائمة.

يعتمد ذلك على الحجم. فالبنية المتوسطة من 20 إلى 50 خادمًا تستغرق من 3 إلى 6 أشهر، والبيئة المؤسسية التي تضم من 100 إلى 300 خادم وعدة قواعد بيانات تستغرق من 6 إلى 12 شهرًا، وقد تصل المحافظ الكبيرة متعددة المواقع إلى مدة من 12 إلى 24 شهرًا. والمهم ليس المدة الإجمالية بل إيقاع الموجات: ننفذ الترحيل في موجات مدة كل منها من أسبوعين إلى 3 أسابيع، تضم كل موجة من 5 إلى 15 حمل عمل. وبذلك تتوزع المخاطر، ويتعلم فريقك، ويبقى طريق التراجع مفتوحًا. ولا ننفذ عمليات انتقال دفعة واحدة (Big Bang) لسبب واضح: فخطأ صغير في يوم الانتقال قد يتحول إلى أزمة كبيرة. والنهج التدريجي هو الأكثر أمانًا دائمًا.

نعم إذا صُمّم الحل بشكل صحيح، فالوفر الصافي بنسبة 20-50% أمر طبيعي. أما التصميم الخاطئ فيجعل السحابة أغلى. مصادر الوفر: الإيقاف التلقائي في ساعات عدم الاستخدام، وخصومات بنسبة 40-65% عبر Reserved Instances وSavings Plans، وبنسبة 70-90% عبر مثيلات Spot لأحمال المعالجة الدفعية، وخفض تكلفة فرق التشغيل بفضل الخدمات المدارة. مصادر زيادة التكلفة: حركة البيانات بين مناطق التوفر (Cross-AZ)، ونقل البيانات الصادرة (Egress)، والمثيلات المبالغ في حجمها، وبيئات الاختبار غير الخاضعة للمراقبة. لذلك فإن انضباط FinOps شرط أساسي: تحليل شهري للاستخدام، وكشف الحالات الشاذة، وتوصيات ضبط حجم الموارد (Right-Sizing). ويعمل 88% من عملائنا بتكلفة أقل من تكلفتهم الإجمالية السابقة للملكية (TCO) بنهاية أول 12 شهرًا.

هدفنا انقطاع من 0 إلى 30 دقيقة لكل حمل عمل. ويمكن ترحيل تطبيقات الويب عديمة الحالة (Stateless) دون انقطاع عبر النشر الأزرق-الأخضر (Blue-Green). أما قواعد البيانات فلها نهجان: (1) النسخ المتماثل المستمر بأدوات مثل AWS DMS وGoogle DMS وAzure DMS، إذ ننتظر عند الانتقال من دقيقة إلى 5 دقائق ريثما يتقلص التأخر ثم نحوّل DNS؛ (2) انقطاع مخطط له ضمن نافذة صيانة، وعادة ما تكون فترة ليلية من ساعتين إلى 6 ساعات. ونختار بحسب احتياجات العمل. وتُجرى بروفة لكل عملية انتقال مسبقًا، فلا مفاجآت في بيئة الإنتاج. وإذا ظهرت مشكلة تتجاوز الوقت المخطط له، أعاد التراجع (Rollback) الجاهز الأنظمة إلى الخوادم المحلية.

نعم في الغالب، لكن يجب تحويلها. فالنسخ الاحتياطية المبنية على VMware أو Hyper-V تُحوَّل إلى صيغ AWS أو GCP أو Azure ثم تُشغَّل، ولهذا نبدأ أول تجربة بتشغيل نسخة منها في السحابة لاختبار البيانات والتوافق. لكن النسخة الاحتياطية ليست ترحيلًا: فقد تكون الإعدادات قديمة، وقد تعمل التراخيص بطريقة مختلفة، ويجب إعادة ضبط الشبكة. ومع ذلك تسرّع النسخ الاحتياطية البداية كثيرًا. ونبني مع الترحيل استراتيجية نسخ احتياطي Cloud-Native: أتمتة اللقطات (Snapshots)، والنسخ المتماثل بين المناطق، ونسخ احتياطية غير قابلة للتعديل (Immutable) تصمد حتى أمام برامج الفدية.

يمكن للعملاء الذين يتخذون من تركيا مقرًا لهم استخدام منطقة AWS في إسطنبول، أو منطقة Microsoft Azure في تركيا، أو شركاء تركيين من مزودي السحابة الكبار (Hyperscalers). وللعمليات التي يقع مقرها في الاتحاد الأوروبي نوصي بمناطق أوروبية مثل فرانكفورت وأمستردام ودبلن، مع منطقة هبوط (Landing Zone) تتوافق مع لائحة GDPR الأوروبية. أما الضوابط الحرجة لامتثال قانون حماية البيانات الشخصية التركي رقم 6698 (KVKK) وGDPR فهي: اختيار منطقة تضمن بقاء البيانات في موقعها، والتشفير أثناء التخزين والنقل، والاحتفاظ بسجلات التدقيق لمدة 7 سنوات، والوصول القائم على الأدوار عبر IAM، وتقرير امتثال شهري لمسؤول حماية البيانات (DPO). ويمكن أيضًا اعتماد نماذج هجينة تُبقي أحمال العمل الحساسة محليًا وتنقل الباقي إلى السحابة العامة. ونعدّ مصفوفة الامتثال مع فريقك القانوني.

نعم، فنحن نخطط لذلك في كل مرحلة. أول 90 يومًا هي أسهل فترة للتراجع: فالنظام المحلي ما زال يعمل، ويكفي عكس تغيير DNS لإعادة توجيه حركة البيانات. وبين اليوم 90 واليوم 180 يبدأ إيقاف النظام المحلي تدريجيًا، وتتطلب العودة عقود عتاد جديدة، لكنها تظل ممكنة لأن البيانات تبقى متزامنة. وبعد 12 شهرًا لا تكون العودة الكاملة عملية، لكن يمكن دائمًا الانتقال إلى نموذج هجين ونقل بعض أحمال العمل الحرجة إلى مركز بيانات خاص. والشعور بأن قرار السحابة لا رجعة فيه شعور خاطئ، فالتخطيط الصحيح يحافظ على المرونة. ولتقليل الارتباط بمورد واحد (Vendor Lock-in) نبني طبقات مستقلة عن مزود السحابة (Kubernetes وTerraform والمعايير المفتوحة).

من عبء الخوادم المحلية إلى سحابة منضبطة.

لنراجع معًا في اجتماع مجاني لمدة 30 دقيقة بنيتك التحتية الحالية، وموعد تجديد العتاد، وسيناريوهات الترحيل إلى السحابة، لتخرج بخارطة طريق واضحة من 3 خطوات.

احجز اجتماعًا تواصل معنا

النداء الأخير للخوادم المحلية. اليوم الأول في السحابة.