نعم، الانتقال بين الاستضافة السحابية وOn-Premise ممكن دون خسارة إذا كانت المنصة نفسها تعمل في النموذجين، وكان حقك في الانتقال وما تستلمه عنده مكتوبًا في العقد. الانتقال هنا نقل بيئة لا تغيير نظام: تُنقل قاعدة البيانات والملفات والفيديو والإعدادات والسجلات كما هي، ثم يُعاد ربط ما يتغير بتغير المكان: الدخول الموحد، والتكاملات، والنطاق وروابط التحقق من الشهادات، وخدمات الرسائل والبريد. الخطة الآمنة: نقل تجريبي واختبار، ثم تجميد قصير ونقل نهائي في فترة هادئة، وبيئة قديمة للقراءة فقط حتى تُعتمد المطابقة، ثم إغلاقها بحذف موثق.
لماذا تنتقل الجهات بين السحابة وخوادمها؟
نادرًا ما يكون الانتقال قرارًا تقنيًا خالصًا. في أغلب الحالات يتغير شيء خارج إدارة تقنية المعلومات، فيصبح النموذج الذي اختير قبل سنوات غير مناسب. والسؤال الأول ليس «كيف ننتقل؟» بل «هل السبب يستلزم الانتقال فعلًا، وإلى أي نموذج؟».
| الاتجاه | السبب | تحقق أولًا |
|---|---|---|
| من السحابة إلى On-Premise | سياسة جديدة أو كراسة أو عقد يشترط التشغيل داخل مركز بيانات الجهة | نص الشرط: هل يطلب مركز بيانات الجهة، أم بيئة غير مشتركة داخل المملكة تحققها سحابة خاصة؟ |
| من السحابة إلى On-Premise | الحاجة إلى شبكة معزولة كليًا أو جزئيًا عن الإنترنت | الخدمات التي تحتاج اتصالًا خارجيًا في أي نموذج، كالرسائل وبعض أدوات الاجتماعات |
| من السحابة إلى On-Premise | تفضيل الأصل الرأسمالي على الاشتراك | التكلفة الكاملة للتشغيل الداخلي، لا الترخيص وحده |
| من On-Premise إلى السحابة | إغلاق غرفة الخوادم أو مركز البيانات ضمن خطة تحول | اتصال المواقع والفروع بالإنترنت، وكانت تصل المنصة عبر الشبكة الداخلية |
| من On-Premise إلى السحابة | تقلص فريق البنية التحتية أو انشغاله بأنظمة أهم | من سيتولى ما كان الفريق يفعله: المراقبة والنسخ والتحديث |
| في الاتجاهين | اندماج أو استحواذ يوحّد أنظمة الجهتين | نموذج الجهة الأم وسياساتها قبل نقل أي شيء |
الصف الأول هو الأكثر إساءة للفهم. «بقاء البيانات داخل المملكة» شرط تحققه السحابة المحلية، و«بيئة غير مشتركة» تحققه السحابة الخاصة، و«التشغيل داخل مركز بيانات الجهة» وحده يستلزم On-Premise. قراءة النص بدقة قد توفر عليك انتقالًا كاملًا، والمفاضلة بين الخيارات الثلاثة في دليل متى تختار السحابة الخاصة.
الانتقال بين النماذج ليس تغييرًا للمنصة
حين تستبدل منصة بأخرى، تنقل بياناتك بين نظامين مختلفين في بنية البيانات: تصدّر، وتنظّف، وتطابق الحقول، وتقبل أن بعض الأشياء لن تنتقل كما هي. هذا مشروع ترحيل كامل بمخاطره، ومشروح في دليل نقل البيانات من LMS إلى آخر.
أما إن كانت المنصة واحدة في النموذجين، كما في نماذج الاستضافة الثلاثة للمنصة التعليمية حيث الوحدات والتقارير والتكاملات والضوابط ثابتة، فالانتقال نقل للبيئة نفسها: قاعدة البيانات بجداولها، والملفات بمساراتها، والإعدادات كما هي. لا مطابقة حقول ولا إعادة بناء للدورات. المخاطر هنا مختلفة: ليست في تحويل البيانات، بل في كل ما يرتبط بالمكان، كالعناوين والشهادات الأمنية والاتصال بالأنظمة الأخرى وتطابق الإصدار بين البيئتين.
إن كان مزودك الحالي يقدم النموذج السحابي فقط، والنموذج الذي تحتاجه لا يقدمه، فأنت أمام تغيير منصة لا انتقال بين نماذج. اعرف ذلك قبل أن تبني خطتك على افتراض أن النقل «نسخ ولصق».
ما الذي يُنقل؟ جرد الطبقات الخمس
أكثر ما يُنسى في الانتقال ليس البيانات، بل ما حولها. جرّد الطبقات الخمس قبل أي تاريخ، واطلب لكل طبقة طريقة تحقق بعد النقل:
| الطبقة | ما تشمله | كيف تتحقق بعد النقل |
|---|---|---|
| البيانات | المستخدمون والهيكل، والتسجيلات والتقدم، والدرجات والمحاولات، والحضور، وسجلات الشهادات، وبنك الأسئلة، والاستبيانات ونتائجها | تقرير مطابقة بالأعداد لكل نوع، وعينة من السجلات الفردية تُقارن في البيئتين |
| الملفات | الفيديو، وحزم SCORM وH5P، والمرفقات، وتسليمات الواجبات، وملفات الشهادات الصادرة | عدد الملفات وحجمها الإجمالي، وتشغيل عينة من كل نوع |
| الإعدادات | الأدوار والصلاحيات، والهوية والقوالب، وقوالب الإشعارات، وقواعد الإسناد، وإعدادات الدخول والتكاملات | مقارنة الإعدادات قبل وبعد، ودخول بحساب من كل دور |
| السجلات | سجل العمليات وسجلات الدخول للفترة التي تفرض سياستكم الاحتفاظ بها | استعلام عن عمليات قديمة معروفة في البيئة الجديدة |
| النسخ الاحتياطية | النسخ القائمة في البيئة القديمة وسياسة الاحتفاظ بها | قرار مكتوب: ما يُنقل، وما يُحفظ مؤقتًا، وما يُحذف ومتى |
طبقة السجلات تستحق انتباهًا خاصًا. سجل العمليات في المنصة يحفظ كل دخول وإضافة وتعديل وحذف باسم المستخدم ووقته وعنوان IP والقيمة قبل التغيير وبعده، ولا يُعدّل من الواجهة، ومدة الاحتفاظ به تتبع سياسة جهتك. إن لم ينتقل مع البيانات انقطع تاريخ التدقيق عند يوم الانتقال، وقد يسأل المدقق بعد عام عن تعديل درجة وقع قبله.
ما الذي يتغير بتغير المكان؟
البيانات تنتقل كما هي، لكن هذه العناصر يجب أن يُعاد ضبطها، وكل منها يحتاج مالكًا في خطتك:
- الدخول الموحد: الربط مع Active Directory أو LDAP داخل الشبكة يعمل في On-Premise دون فتح منافذ خارجية. عند الانتقال إلى السحابة يُبحث في التحليل كيف يصل الدخول الموحد إلى نظام الهوية، مثلًا عبر Entra ID أو Google Workspace إن كانا مستخدمين، كما في صفحة الدخول الموحد.
- التكاملات: كل ربط مع الموارد البشرية أو غيرها له عنوان وصلاحيات وقواعد جدار ناري تتغير. أعد اختبار كل تكامل على بيئة الاختبار قبل التحول.
- النطاق وروابط الشهادات: رمز QR على كل شهادة صادرة يحمل رابطًا. إن تغير النطاق دون تحويل للروابط القديمة صارت الشهادات السابقة غير قابلة للتحقق.
- البريد والرسائل: الإشعارات في On-Premise قد تمر عبر خادم البريد الداخلي للجهة، وقد يتغير مسارها بعد الانتقال إلى السحابة، فحدد في التحليل من أين يُرسل البريد وكيف تنتقل إعدادات مزود الرسائل النصية.
- الشهادات الأمنية والمراقبة والنسخ: من يتولاها يتغير مع النموذج، فاكتب تاريخ انتقال المسؤولية لا تاريخ النقل فقط.
خطة الانتقال: ست مراحل
- القرار والنطاقالسبب، والنموذج الهدف، وجرد الطبقات الخمس، وتاريخ لا يتعارض مع ذروة التدريبتقنية المعلومات والتدريب
- تجهيز البيئة الهدفخوادم الجهة حسب وثيقة المواصفات، أو بيئة المزود السحابية، مع الإصدار نفسه من المنصةالجهة أو المزود حسب الاتجاه
- نقل تجريبي واختبارنسخة كاملة إلى بيئة الهدف، ومطابقة، واختبار الدخول والتكاملات والشهاداتالمزود مع فريقكم
- التجميد والنقل النهائيإيقاف التعديل لفترة قصيرة معلنة، ثم نقل آخر نسخة من البيانات والملفاتالمزود
- التحولتوجيه النطاق، وتفعيل الدخول الموحد والتكاملات على البيئة الجديدة، واختبار سريع بعد التحولتقنية المعلومات
- القراءة فقط ثم الإغلاقالبيئة القديمة للمراجعة حتى تُعتمد المطابقة، ثم حذف موثقتقنية المعلومات والمزود
في الانتقال إلى On-Premise تتبع المرحلة الثانية مراحل مشروع التشغيل على خوادمكم: وثيقة مواصفات الخوادم قبل شراء أي جهاز، ثم بيئة اختبار ثم إنتاج، وأدلة تشغيل ونقل معرفة لفريقكم. ومتطلبات البنية والفريق التي تسبق ذلك في دليل متطلبات خوادم LMS. وفي الانتقال إلى السحابة تُجهز البيئة لدى المزود داخل المملكة، ويُذكر المزود ومكان الاستضافة في العرض الفني، كما في صفحة الاستضافة داخل السعودية.
التوقيت والتشغيل المتوازي
متى تنقل؟
اختر فترة لا تقع فيها ذروة: لا نافذة تدريب إلزامي، ولا اختبارات نهائية، ولا بداية فصل، ولا إغلاق سنة. واجعل عقد البيئة القديمة يمتد بعد تاريخ الانتقال المخطط بهامش يكفي لتأجيله إن فشل النقل التجريبي. أسوأ انتقال هو الذي يحدد تاريخه انتهاءُ عقد لا جاهزيةُ البيئة.
ماذا يعني التشغيل المتوازي هنا؟
في استبدال منصة بأخرى، قد تعمل المنصتان معًا أسابيع، لكل منهما مستخدمون ودورات، كما في دليل التشغيل المتوازي لنظامي LMS. في الانتقال بين النماذج لا يُنصح بذلك: البيئتان نسختان من النظام نفسه، وتشغيلهما معًا للكتابة يعني بيانات تتفرع ولا تجتمع. التشغيل المتوازي الصحيح هنا أن تعمل البيئة الجديدة وحدها للعمل اليومي، وتبقى القديمة للقراءة فقط بصلاحيات محدودة لفريق المطابقة والتدقيق، حتى تعتمدوا تقرير المطابقة، ثم تُغلق.
تفكر في تغيير نموذج الاستضافة؟ نراجع معك السبب والنموذج الهدف وجرد ما يُنقل، قبل أن تلتزم بتاريخ.
خطط الانتقال مع فريقناما يجب كتابته في العقد من اليوم الأول
أرخص وقت للتفاوض على الانتقال هو يوم التعاقد الأول، حين لا يكون المزود متأكدًا أنك باقٍ. هذه البنود تجعل أي انتقال لاحق خطة لا أزمة:
- حق الانتقال بين النماذج: نص صريح بأن الجهة تستطيع الانتقال إلى نموذج آخر يقدمه المزود، وأن المنصة والوظائف واحدة فيه.
- ما يُسلّم عند الانتقال أو انتهاء العقد: قاعدة البيانات كاملة، والملفات، والإعدادات، وسجل العمليات، بصيغة مقروءة، مع وصف لبنية البيانات. البيانات والمحتوى ملك الجهة مع حق التصدير.
- أساس تسعير الانتقال: هل خدمة النقل مشمولة أم تُسعر مشروعًا، وما الذي يحدد تكلفتها. واسأل كيف يُعامل الاشتراك المدفوع عند التحول إلى ترخيص دائم، والعكس، واطلب الإجابة مكتوبة.
- تطابق الإصدار: أن تكون البيئة الهدف على إصدار المنصة نفسه عند النقل، حتى لا يجتمع الانتقال والترقية في يوم واحد.
- ملكية النطاق: أن يكون نطاق المنصة باسم الجهة لا المزود، حتى تبقى روابط التحقق من الشهادات صالحة بعد أي انتقال.
- الحذف بعد الانتقال: حذف البيانات والنسخ الاحتياطية من البيئة القديمة بعد اعتماد المطابقة، بتأكيد مكتوب وتاريخ.
وراجع مع هذه البنود سياسة النسخ الاحتياطي في كل نموذج، لأن النسخ القديمة جزء من بياناتك أيضًا، وتفصيلها في دليل النسخ الاحتياطي والتعافي لنظام LMS.
سيناريو: شركة تعدين تغلق غرفة خوادمها
مثال افتراضي للتوضيح شركة تعدين ومحاجر بنحو 2,800 موظف في مقر رئيسي وخمسة مواقع تشغيل بعيدة عن المدن، شغّلت المنصة على خوادمها أربع سنوات. الموظفون في المواقع يصلون إليها عبر الشبكة الداخلية الواصلة بين المواقع والمقر، والدخول بحسابات Active Directory، وتدريب السلامة الحضوري في المواقع يُسجل حضوره برمز QR، وشهادات السلامة بصلاحية سنوية. ثم قررت الشركة إغلاق غرفة الخوادم ونقل أنظمتها المساندة إلى السحابة.
ظهر في جلسة النطاق ما لم يكن في الحسبان:
- اتصال المواقع: المنصة كانت تصل المواقع عبر الشبكة الداخلية، وبعد الانتقال ستصلها عبر الإنترنت. فقبل أي تاريخ، قاست تقنية المعلومات قدرة اتصال كل موقع على تشغيل فيديوهات السلامة في وقت تغيير الوردية.
- الدخول الموحد: الربط مع Active Directory كان داخل الشبكة. اختارت الشركة الدخول عبر نظام الهوية السحابي المتزامن مع دليلها، وحُدد ذلك في التحليل واختُبر على بيئة الاختبار.
- روابط الشهادات: اكتُشف أن رابط التحقق في شهادات السنوات الأربع على نطاق داخلي لا يُفتح من خارج الشبكة أصلًا. فنُقل التحقق إلى نطاق عام باسم الشركة، مع تحويل الروابط القديمة، فصارت الشهادات السابقة قابلة للتحقق من الخارج لأول مرة.
- التوقيت: أُجّل النقل النهائي عن شهر تجديد شهادات السلامة، وامتد عقد صيانة الخوادم القديمة شهرين بعد التاريخ المخطط احتياطًا.
انتهى الانتقال ببيئة قديمة للقراءة فقط حتى اعتمد فريق التدريب تقرير المطابقة، ثم مُسحت الخوادم بمحضر. لم يتغير على الموظفين شيء غير طريقة الدخول؛ الدورات والسجلات والشهادات كما تركوها.
أخطاء تتكرر في الانتقال بين النماذج
- الانتقال لسبب يحققه نموذج أقرب: نقل كامل إلى On-Premise بينما كان الشرط بيئة غير مشتركة تحققها سحابة خاصة.
- نقل البيانات دون السجلات: يبدأ سجل التدقيق من يوم الانتقال، ويضيع ما قبله.
- تغيير النطاق دون تحويل: كل شهادة صادرة قبل الانتقال تفقد قابلية التحقق.
- الجمع بين الانتقال والترقية: إن ظهرت مشكلة فلن تعرف مصدرها.
- ترك البيئة القديمة تعمل للكتابة: بيانات تتفرع، ومطابقة لا تنتهي.
- إغلاق القديمة دون حذف موثق: بيانات الموظفين باقية على خوادم أو لدى مزود لم يعد مسؤولًا عنها.
الأسئلة الشائعة
لا يجب أن تخسر شيئًا إن كانت المنصة واحدة في النموذجين ونُقلت الطبقات الخمس كاملة. الخسارة تحدث عادة فيما حول البيانات: سجلات لم تُنقل، أو روابط شهادات تغير نطاقها، أو تكامل لم يُعد ضبطه. تقرير المطابقة والاختبار قبل التحول هما ما يثبت ذلك.
يتوقف التعديل فقط خلال فترة التجميد القصيرة قبل النقل النهائي، وتُعلن مسبقًا وتُختار خارج أوقات الذروة. ويمكن ترتيبها بحيث يبقى التعلم الذاتي أقل تأثرًا، وتُحدد التفاصيل بعد النقل التجريبي الذي يكشف الوقت الفعلي للنقل.
يعتمد على حجم الملفات والفيديو، وعدد التكاملات، وجاهزية البيئة الهدف، وفي الانتقال إلى On-Premise على جاهزية الخوادم والاعتمادات الأمنية لدى الجهة. تُحدد المدة في العرض الفني بعد التحليل، والنقل التجريبي هو أدق مؤشر على مدة النقل النهائي.
نعم في الغالب، لأن النموذج السحابي اشتراك سنوي، وOn-Premise ترخيص دائم مع عقد صيانة سنوي. اسأل المزود كتابة كيف يُعامل ما دفعته في النموذج الحالي عند التحول، واجعل ذلك بندًا في العقد الأول إن استطعت.
نعم، والخطة نفسها تنطبق. وقد تكون السحابة الخاصة الوجهة الأنسب حين يكون سبب الانتقال سياسة تمنع البيئات المشتركة دون أن تشترط مركز بيانات الجهة.
الخلاصة: الانتقال الآمن يُكتب قبل أن يُحتاج
الانتقال بين الاستضافة السحابية وOn-Premise مشروع صغير نسبيًا حين تكون المنصة واحدة في النموذجين: لا تحويل للبيانات ولا إعادة بناء. لكنه يفشل في التفاصيل المحيطة: السجلات، والنطاق، والدخول الموحد، والتكاملات، والتوقيت، والحذف. اجرد الطبقات الخمس، ونفذ النقل التجريبي قبل تحديد التاريخ، وأبقِ القديمة للقراءة فقط حتى تعتمد المطابقة.
وإن كنت ما زلت في مرحلة الاختيار، فاكتب بنود الانتقال في عقدك الأول، وقارن النموذجين في مقارنة السحابي وOn-Premise. وإن كانت المنصة التعليمية تعمل لديك اليوم وتغيرت سياسة جهتك، فناقش مع فريقنا خطة الانتقال قبل أن يفرض انتهاء عقد أو موعد تدقيق تاريخها. وصورة ما تقدمه المنصة للشركات بالنماذج الثلاثة في صفحة الشركات.