ترحيل لوحة SMS: من SaaS إلى الاستضافة الذاتية خطوة بخطوة

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

المرحلة 0: حدّد الجدول الزمني وفق أبطأ بند

قبل أن تلمس البيانات، اكتب قائمة بالأمور التي تسير وفق ساعة غيرك: إعادة تسجيل معرّفات المرسل والأرقام القصيرة باسم كيانك، والهويات التنظيمية (DLT في الهند، و10DLC في الولايات المتحدة، وما يعادلهما في غيرهما)، وموافقات المشغّلين على روابط SMPP (bind) الخاصة بك، وتوثيق Meta لنشاطك التجاري إن أضفت WhatsApp. كل واحد منها يستغرق أسابيع لا أيامًا، ولا يوجد وقت مبكر أكثر من اللازم للبدء بأي منها. ابدأها كلها في الأسبوع الأول، بالتوازي مع كل ما يلي، وسينتهي باقي الترحيل وهو ينتظرها، لا العكس.

المرحلة 1: جرد ترحيل لوحة SMS

دوّن، من واجهة الإدارة في اللوحة، سطرًا واحدًا لكل بند:

• العملاء: كل حساب، ووضع الفوترة الخاص به (رصيد مسبق الدفع، أو محفظة، أو دفع لاحق)، ورصيده الحالي، وخطة أسعاره، والشخص المسؤول عن التواصل فيه، وما إذا كان يتكامل عبر لوحة التحكم أو HTTP API أو ربط SMPP (bind).
• خطط الأسعار والمسارات: كل خطة أسعار، وكل سطر وجهة، وكل مسار مورّد مع بيانات اعتماده وتكلفته.
• معرّفات المرسل والأرقام: المعرّفات الأبجدية الرقمية، والأرقام الطويلة، والأرقام القصيرة، والكيان الذي سُجّل كل منها باسمه لدى كل مشغّل.
• التكاملات: كل اسم مضيف يستدعيه عملاؤك (API، ورابط اللوحة، ونقاط نهاية webhook التي يتلقّون عليها إشعارات التسليم)، وما إذا كان على نطاقك أم على نطاق المزوّد.
• أحجام البيانات: جهات الاتصال، والقوالب، وسجل الحملات، وسجلات التسليم، والفواتير، شهرًا بشهر.
• العقود: مدة الإشعار المسبق في عقد اللوحة، وكل عقد عميل يذكر اسم اللوحة أو رابطها.

هذا الجرد هو خطة الترحيل. وكل ما يلي هو الجرد نفسه وقد أُضيفت إليه التواريخ.

المرحلة 2: احصل على ملفات تصدير حقيقية ما دمت عميلًا

اطلب التصدير الآن، قبل أن تقدّم إشعار الإنهاء، لأن الرد يكون أكثر تعاونًا ما دمت تدفع. اطلب كل بند في الجرد بصيغة تقرؤها الآلة (صيغة CSV تكفي) وافتح كل ملف: قارن عدد الصفوف بما تعرضه لوحة التحكم، وتحقّق من أن سجلات الموافقة تنتقل مع جهات الاتصال، ومن أن سجلات التسليم تحمل معرّف الرسالة والحالة النهائية لا مجرد عدد. عبارة «ندعم التصدير بصيغة CSV» وعبارة «الملف يحتوي على ما يحتاجه عملائي» جملتان مختلفتان.

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

المرحلة 3: أقم المنصة الجديدة على نطاقك الخاص

ثبّت المنصة على خادمك الخاص وعلى نطاقك الخاص قبل أن ينتقل أي عميل. قاعدتان من دليل المقارنة تسريان من هذا اليوم فصاعدًا: اللوحة وواجهة API تعيشان على أسماء مضيفين تملكها (panel.yourcompany.com و api.yourcompany.com)، ومعرّفات المرسل والهويات التنظيمية تُسجَّل باسم كيانك حيثما سمح المنظّم بذلك. ثم:

1. اربط عقودك الخاصة مع المشغّلين بوصفها مسارات مورّدين، واختبر كلًّا منها بهواتف حقيقية في كل وجهة قبل أن تمرّ عليه أي حركة من العملاء.
2. أعد بناء خطط الأسعار من ملف التصدير، لكل وجهة ولكل فئة من العملاء، وضع حدًّا أدنى للهامش تحت كل سطر (يشرح دليل الفوترة أوضاع الفوترة الثلاثة، ولماذا يُختار الوضع عند إنشاء الحساب ويُقفل بعده، فاحسمه الآن).
3. أنشئ حسابات العملاء بوضع الفوترة الصحيح وخطة الأسعار ومعرّفات المرسل وجهات التواصل، لكن مع تعطيل الإرسال وإبقاء الأرصدة عند الصفر حتى التحويل النهائي.
4. استورد جهات الاتصال وسجلات الموافقة والقوالب. نصيحة عملية نقدّمها لكل مشترٍ: استورد سجلات الاشتراك (opt-in) مع جهات الاتصال، فتكون ممتثلًا من اليوم الأول بدل أن تعيد بناء الموافقات لاحقًا.
5. استورد السجل التاريخي إن استطعت. يستحق سجل الحملات وسجلات التسليم أن تنقلهما كي يحتفظ العملاء بتقاريرهم؛ وفي Smppcube هذا هو الفرق بين الاستيراد القياسي (جهات الاتصال والقوالب وإعدادات المرسل والمسارات) والترحيل الكامل (كل ذلك إضافةً إلى سجل الإرسال والحملات وسجلات الفوترة) في صفحة الأسعار.
6. جهّز خادم SMPP للعملاء الذين يرتبطون عبر bind، مع بيانات اعتماد لكل حساب، وسقوف للإنتاجية، وقوائم عناوين IP المسموح بها، جاهزة للتسليم؛ وفي Smppcube يُعدّ خادم SMPP وواجهة HTTP API جزءًا من المنصة، لا إضافة منفصلة.

المرحلة 4: البنود التي لا تنتقل

أربعة أمور يحتاج كل منها إلى خطة خاصة، لأن أي ملف تصدير لا يحملها.

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

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

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

روابط SMPP (bind). يحتاج كل عميل يرتبط عبر bind إلى بيانات جديدة: المضيف، والمنفذ، وsystem_id، وكلمة المرور، وعناوين IP المسموح بها، وسقف الإنتاجية، وإلى نافذة اختبار على مسار الاختبار لديك قبل أن تنتقل حركته الفعلية. أرسل حزمة بيانات الاعتماد في مستند واحد، وحدّد موعدًا لاختبار مدته 30 دقيقة مع مهندسه.

يفشل الترحيل بسبب البنود التي لم يصدّرها أحد، لا بسبب تلك التي صدّرها الجميع. أسماء المضيفين وعناوين webhook ومعرّفات المرسل وروابط bind هي الخطة؛ أما ملفات CSV فهي الجزء السهل.

المرحلة 5: التشغيل المتوازي

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

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

المرحلة 6: التحويل النهائي، عميلًا تلو الآخر

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

التواصل هو معظم العمل. رسالة قصيرة إلى كل عميل قبل شهر («ننتقل إلى منصتنا الخاصة، وهذا ما يتغيّر بالنسبة إليك، وهذا ما لا يتغيّر»)، وتذكير قبل أسبوع بتاريخه المحدد، وتأكيد في اليوم نفسه. يغادر العملاء بسبب المفاجآت، لا بسبب التغييرات.

المرحلة 7: أوقف اللوحة القديمة كما ينبغي

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

ما الذي يكلّفه الترحيل، وما الذي يستحقه

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