تحويل البرنامج إلى SaaS: دليل الانتقال لناشري البرمجيات

يعمل برنامجكم على أجهزة عملائكم أو خوادمهم. كل إصدار جديد يعني ملفات تثبيت توزَّع، وفريق دعم يتعامل مع عدة إصدارات في وقت واحد. في المقابل، يريد عملاؤكم العمل من أي مكان، ويفضّل بعضهم الاشتراك على شراء ترخيص. إن كنتم تتساءلون عن طريقة تحويل البرنامج إلى SaaS (البرمجيات كخدمة، أي برنامج يُستخدم عبر الإنترنت مقابل اشتراك)، فهذا الدليل لكم: لناشري البرمجيات، وللشركات التي تملك أداة داخلية وتريد بيعها.

نعرض ما الذي يتغير، والمسارات الثلاثة للانتقال، وكيف تصطحبون عملاءكم الحاليين معكم.

ما الذي يتغير فعلاً عند تحويل البرنامج إلى SaaS

لن تبيعوا بعد الآن منتجاً يشغّله عملاؤكم لديهم، بل ستديرون خدمة يستخدمونها. وتتغير خمسة أمور.

البنية: منصة واحدة لعملاء كثيرين

البرنامج المثبَّت يخدم عميلاً واحداً في كل تثبيت. أما تطبيق SaaS فيخدمهم عادةً جميعاً من منصة واحدة، وهو ما يُسمّى البنية متعددة المستأجرين (multi-tenant). يجب أن تبقى بيانات كل عميل منفصلة تماماً، وأن يعرف كل طلب العميلَ الذي ينتمي إليه، وأن تنتقل الإعدادات التي كانت في ملف محلي إلى قاعدة البيانات. ويحتاج برنامج سطح المكتب أيضاً إلى واجهة جديدة، وهي في الغالب تطبيق ويب يُفتح في المتصفح.

التحديثات: إصدار واحد للجميع

لا مزيد من ملفات التثبيت، ولا مزيد من العملاء المتأخرين بثلاثة إصدارات. تنشرون إصداراً واحداً للجميع، بالوتيرة التي تحتاجون إليها. وهذا يتطلب Automation للاختبارات والنشر، لأن أي خطأ يصل الآن إلى جميع عملائكم دفعة واحدة.

التشغيل والأمن: الخوادم مسؤوليتكم

تصبح الاستضافة و Backup والمراقبة والتوفر والأمن من مسؤوليتكم. فبيانات عملائكم أصبحت لديكم، وأنتم مسؤولون عن حمايتها.

الدعم: بيئات أقل، وتوقعات أعلى

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

نموذج العمل: اشتراكات بدلاً من التراخيص

تصل الإيرادات كل شهر أو كل سنة، بدلاً من صفقة كبيرة يتبعها عقد صيانة. وتتغير أيضاً الأسعار والعقود والسيولة، كما سنرى أدناه.

ثلاثة مسارات للانتقال، من الأسرع إلى الأشمل

1. الاستضافة: برنامجكم على خوادمكم

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

2. التحديث التدريجي للمنصة

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

3. إعادة البناء كتطبيق SaaS أصيل

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

جدول القرار

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

ملاحظة صريحة: إن كان عملاؤكم قليلين وراضين وغير مستعجلين على التغيير، فقد لا يستحق التحويل الكامل العناء بعد. وقد يكفي حالياً عرض مستضاف لمن يطلبه.

الانتقال إلى نموذج SaaS: الأسعار والسيولة والعقود

الأسعار

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

السيولة

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

العقود والمحاسبة

يتحول عقد الترخيص إلى عقد اشتراك: مستويات الخدمة، والتوفر، وساعات الدعم، وملكية البيانات، وإعادتها إلى العميل عند مغادرته. وإن كنتم تستضيفون بيانات شخصية لعملاء في الاتحاد الأوروبي، فإن اللائحة العامة لحماية البيانات (GDPR) تعدّكم عادةً معالجاً للبيانات لحسابهم، وهو ما يستلزم اتفاقية معالجة بيانات مع كل منهم (الوضع في أكتوبر 2026). كما يختلف الاعتراف بالإيرادات والضرائب في الاشتراكات عنها في التراخيص، وتتوقف القواعد على البلد.

يقدّم هذا المقال إرشادات عملية، ولا يغني عن رأي محاسبكم أو محاميكم، اللذين ينبغي أن يؤكدا الجوانب التعاقدية والضريبية والمحاسبية في بلدكم.

كيف تنقلون عملاءكم الحاليين إلى نظام Cloud

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

ابدؤوا بالمتطوعين

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

انقلوا البيانات ثم تحققوا منها

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

أثبتوا أن الإصدار الجديد يتصرف كالقديم

قبل كل انتقال، قارنوا نتائج الإصدار القديم والجديد على الحالات نفسها: هذا هو دور Parity tests.

حدّدوا جدولاً زمنياً واضحاً للإصدار المثبَّت

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

طبّقوا Automation مبكراً

النشر القائم على Automation هو ما يجعل «إصداراً واحداً للجميع» ممكناً. وقد عاش مؤسسنا هذه التجربة في Orange Business Services، مع أداة ما قبل البيع يستخدمها أكثر من 500 شخص: CI باستخدام Jenkins و SonarQube، وتجهيز محطات عمل Banque Populaire بنقرة واحدة بدلاً من نصف يوم أو أكثر. اكتشفوا هذا المشروع.

قائمة التحقق قبل أن تبدؤوا

هل نعرف أي العملاء يريدون SaaS، ولماذا؟
هل اخترنا مساراً (الاستضافة، أو التحديث التدريجي، أو إعادة البناء)، وهل نستطيع تفسير هذا الاختيار؟
هل بيانات كل عميل منفصلة، وهل هذا الفصل مختبَر؟
هل تغطي الاختبارات القائمة على Automation قواعد العمل الرئيسية؟
هل يقوم النشر و Backup والمراقبة على Automation؟
هل راجع محاسبنا خطة السيولة والاعتراف بالإيرادات؟
هل راجع محامٍ عقد الاشتراك وبنود معالجة البيانات؟
هل لدينا عملاء تجريبيون، وسكربت Migration، وجدول زمني منشور للإصدار المثبَّت؟

كل إجابة بكلمة «لا» خطوة في خارطة طريقكم، وخبرتنا في حلول SaaS تغطيها جميعاً.

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

هل يمكن تحويل برنامج سطح المكتب إلى نظام Cloud دون إعادة كتابته؟

جزئياً. فاستضافته وإتاحة الوصول عن بُعد ممكنان دون تغييرات كبيرة، وهما وسيلة جيدة لاختبار الطلب. لكن للاستفادة الكاملة من SaaS (إصدار واحد للجميع، وواجهة في المتصفح، وتكلفة تشغيل أقل لكل عميل)، يجب عادةً إعادة بناء الواجهة وطبقة البيانات. أما قواعد العمل فيمكن غالباً إعادة استخدامها إن كانت منفصلة جيداً عن بقية الشيفرة.

هل نواصل بيع الإصدار المثبَّت لدى العملاء؟

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

هل نحتاج إلى البنية متعددة المستأجرين منذ اليوم الأول؟

ليس بالضرورة. فتثبيت مستقل لكل عميل مقبول في البداية، خاصة مع عدد قليل من العملاء. لكن صمّموا النظام منذ البداية بحيث يتيح تعدد المستأجرين: معرّف للعميل في كل سجل، ولا إعدادات في ملفات محلية. سيكون الانتقال لاحقاً أسهل بكثير، لأن التثبيتات المنفصلة تصبح أكثر كلفة في التحديث والمراقبة كلما ازداد عدد العملاء.

الخلاصة

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

هل تفكرون في نقل برنامجكم إلى SaaS؟ احجزوا مكالمة تعريفية مجانية مدتها 30 دقيقة: سندرس معاً منتجكم وعملاءكم ومسار الانتقال الذي يناسبهم.