مرجع الترحيل
ترحيل SugarCRM إلى HubSpot
ما الذي ينتقل فعلًا، وما الذي لا ينتقل دون أن يظهر ذلك، وما الذي يجب إعادة بنائه يدويًا.
طابقنا SugarCRM مع HubSpot ميزةً بميزة: 49 ميزة، و8 كائنات تُزامَن، و7 فخاخ موثقة، و35 بندًا يجب إعادة بنائه. الخريطة كاملة في هذه الصفحة، دون أي نموذج تسجيل.
ملف PDF هو المرجع نفسه، بصيغة تناسب ملف المشتريات.
احصل على المرجع والحاسبة
مرجع SugarCRM إلى HubSpot كاملًا بصيغة PDF، مع حاسبة Excel التي نعتمدها في تحديد نطاق هذه الترحيلات: كل ميزة من الميزات الـ 49 في صف مستقل، تُدخل أعدادك فتحصل على عدد الساعات.
ثلاثة ملفات: المرجع بصيغة PDF، والمرجع نفسه بصيغة Markdown لأداة الذكاء الاصطناعي لديك، وحاسبة الجهد الكاملة بصيغة Excel.
ترحيل SugarCRM إلى HubSpot ترحيل مرتفع التعقيد، وتستغرق مدته عادةً من 4-8 أسابيع. من بين الميزات الـ 49 التي طابقناها، تنتقل 33 ميزة كما هي، وتصل 16 ميزة منقوصة بشيء ما: أما البنود الـ 35 التي لا ينقلها أي شيء نيابةً عنك فهي التي ستحدد جدولك الزمني فعلًا، لا المزامنة.
بطاقة تقييم الترحيل
- تعقيد الترحيل
- مرتفع
- الجدول الزمني المعتاد
- 4-8 أسابيع
- الطريقة الموصى بها
- زامِن ثم رحّل
- المزامنة الأصلية
- مزامنة بيانات، في الاتجاهين
- Smart Transfer
- غير مدعومة
- اشتراك HubSpot
- تعمل المطابقات الافتراضية على الفئة المجانية؛ وأي شيء مخصص يحتاج Data Hub Starter أو أعلى. وجانب Sugar من التكامل الأصلي هو الجزء الذي يستحق تخصيص وقت له أيًا كانت الفئة، لأنه قد يحتاج إلى مطور لإعداده لا إلى مشرف يفعّله، خصوصًا في النسخ المستضافة ذاتيًا (self-hosted).
تكافؤ الميزات عبر 49 قدرة
- يقابله مباشرة: 33 (67%)
- يقابله جزئياً: 16 (33%)
- لا مقابل له: 0 (0%)
8
كائنات تُزامَن أصليًا
7
قيود وفخاخ
35
بنود إعادة بناء يدوية
4
إصدارات المصدر المشمولة
مصدر هذه المعلومات: مجموعة أبحاثنا الخاصة، جرى التحقق منها بتاريخ 2026-07-31، وهي أساس كل رقم في هذه الصفحة.
الكائنات الثمانية التي تُزامَن أصليًا
ما ينقله الموصل نيابةً عنك، واتجاه تدفق كل كائن.
Contacts
في الاتجاهينيصبح Contacts
تقع Leads وContacts في وحدتين (modules) منفصلتين في Sugar إلى لحظة تحويل الـ Lead؛ أما HubSpot فلم تعرف هذا التمييز قط، إذ تحتفظ بكل شيء في كائن Contact واحد. خطّط لمنطق التحويل قبل تشغيل المزامنة، فهذا هو الموضع الوحيد الذي ينظر فيه النظامان إلى العالم بشكل مختلف فعلًا.
Leads
في الاتجاهينيصبح Contacts
يصل كل SugarCRM Lead إلى HubSpot بوصفه Contact مع ضبط مرحلة دورة حياته (lifecycle stage) على 'Lead'. فقدان التمييز بين Lead وContact يبسّط نموذج البيانات فعلًا، لكن فقط بعد أن تُطابَق حقول حالة الـ Lead الكامنة تحته بدل تركها للقيم الافتراضية.
Accounts
في الاتجاهينيصبح Companies
اسم الشركة والنطاق معًا هما ما يحسم ما إذا كان حسابان (Accounts) يُطابَقان بوصفهما واحدًا؛ ومجموعة تدير عدة كيانات خلف نطاق مشترك جديرة بالفحص قبل تشغيل المزامنة، لأن قاعدة الاقتران هذه قد تدمج حسابات يجب أن تبقى منفصلة.
Opportunities
في الاتجاهينيصبح Deals
فعّل مزامنة جهات الاتصال والشركات إلى جانب مزامنة الصفقات لا بعدها، وإلا فإن الروابط (associations) التي تربط الصفقة بالأشخاص والشركات خلفها لن تتشكل ببساطة.
Calls
إلى HubSpotيصبح Calls
تميل مزامنة المكالمات إلى العمل في اتجاه واحد أثناء الترحيل نفسه، والإبقاء عليها في الاتجاهين بعد ذلك يتطلب عادةً تكاملًا من طرف ثالث فوقها. أكّد هذا البند مباشرة قبل أن يدخل أي عرض سعر: فهو غير مدرج بين الكائنات المشتركة في قائمة HubSpot Marketplace الحالية لهذا التطبيق (جرى التحقق بتاريخ 2026-07-31)، ولأن SugarCRM ليس تطبيقًا مدعومًا في HubSpot Smart Transfer فلا يوجد مسار Smart Transfer يُرجع إليه كذلك. وإلى أن يجري التحقق منه، عامله بوصفه غير مؤكد وخطّط لعمل ترحيل يدوي بوصفه الافتراض الأكثر أمانًا.
Meetings
إلى HubSpotيصبح Meetings
تعتمد مزامنة الاجتماعات على إدخال تكامل محدد من طرف ثالث؛ فهي ليست شيئًا يفعله الموصل الأصلي من تلقاء نفسه. وكما في المكالمات، تحقق منه مباشرة ولا تفترضه: هذا الكائن غائب عن قائمة HubSpot Marketplace الحالية لهذا التطبيق (جرى التحقق بتاريخ 2026-07-31)، ولأن SugarCRM ليس تطبيقًا مدعومًا في HubSpot Smart Transfer فلا يوجد مسار Smart Transfer يُعتمد عليه بدلًا منه. أكّده قبل التسعير، لأن مسار مزامنة غير مؤكد يصبح عمل ترحيل يدويًا لحظة يتعذر تحققه.
Tasks
إلى HubSpotيصبح Tasks
لا توجد مزامنة المهام (Tasks) إلا عبر طبقة تكامل موسّعة فوق الموصل الأصلي، لا جاهزةً من العلبة. وينطبق هنا التحذير نفسه كما في غيره من هذه القائمة: فهو لا يظهر بين الكائنات المشتركة في قائمة HubSpot Marketplace الحالية لهذا التطبيق (جرى التحقق بتاريخ 2026-07-31)، وغياب SugarCRM عن قائمة تطبيقات HubSpot Smart Transfer لا يترك مسار نقل يُفحص بدلًا منه. أكّده مباشرة قبل تسعيره، أو احسب له ميزانية بوصفه عمل ترحيل يدويًا.
Notes
إلى HubSpotيصبح Notes
قد تحتاج الملاحظات (Notes)، بما فيها المرفقات، إلى أداة طرف ثالث قبل أن تُزامَن أصلًا بدل أن تنتقل عبر الموصل الأصلي وحده. وهذا بند آخر يُؤكَّد ولا يُفترض: فهو غائب عن قائمة HubSpot Marketplace الحالية لهذا التطبيق (جرى التحقق بتاريخ 2026-07-31)، ولأن SugarCRM لا يملك مسار Smart Transfer كذلك فلا شيء يُرجع إليه إلى أن يجري التحقق منه. عامله بوصفه غير مؤكد، وخطّط لعمل ترحيل يدوي افتراضًا إلى أن يثبت العكس.
سبعة أمور لا تخبرك بها المزامنة
كل أمر منها موثق، وكل أمر منها أنهى ترحيلًا في أسبوع سيئ.
عدم تطابق بنية البيانات: Leads مقابل Contacts
لدى HubSpot كائن Contact واحد، بينما احتفظ SugarCRM بـ Leads وContacts وAccounts جداول أساسية منفصلة طوال الوقت، فيصبح شخص حُوّل من Lead إلى Contact قبل أشهر هو نفسه الصف الذي يشغله من كانوا Contacts منذ البداية. وهذا الانهيار يزيل مشكلة تكرار حقيقية، لكن فقط بعد أن تُطابَق حالة الـ Lead وتاريخ التحويل خلف كل سجل بعناية بدل افتراض أنها ستنصهر بنظافة.
الحل البديل: اضبط مرحلة دورة الحياة (lifecycle stage) على كل SugarCRM Lead مرحَّل لحظة وصوله Contact في HubSpot، واحتفظ بمصدر الـ Lead الأصلي وحالته في خصائص مخصصة بدل ترك الانهيار في كائن واحد يمحو من أين جاء السجل فعلًا.
تكامل SugarCRM الأصلي بطيء ويعتمد على مطور
يفحص موصل HubSpot الأصلي من SugarCRM كل سجل يدويًا بحثًا عن تطابق بدل فهرستها، فيزداد بطؤه كلما زاد عدد جهات الاتصال، ويحتاج إلى مطور لإعداده أصلًا. وفي نسخة Sugar مستضافة ذاتيًا في مركز بيانات محلي، كثيرًا ما تكون قديمة بُنيت على يد مُكامِل لم يعد موجودًا، فإن متطلب المطور هو المشكلة الأصعب: يجب العثور على من يستطيع لمس النسخة بأمان قبل أن يمكن إعداد الموصل أصلًا.
الحل البديل: استخدم تطبيق Data Sync من HubSpot Marketplace بدلًا من الاعتماد على موصل SugarCRM نفسه، أو استعن بأداة طرف ثالث مثل Skyvia أو IntegrateIQ: يتفادى أي من المسارين المطابقة سجلًا بسجل التي تبطئ التكامل الأصلي.
قيد الاتجاه الواحد في موصل SugarCRM الأصلي
التحديثات التي تجري في HubSpot يمكن أن تصل إلى SugarCRM بصورة مقبولة، لكن العكس غير مضمون: فحالة بأهمية 'do not contact' يمكن ضبطها في SugarCRM ولا تعود أبدًا إلى HubSpot، فيختلف النظامان حول تفضيلات جهة الاتصال نفسها.
الحل البديل: يسد تطبيق Data Sync من HubSpot هذه الفجوة بمزامنة حقيقية في الاتجاهين، ويمكن بناء منصة تكامل من طرف ثالث لتحقيق الأثر نفسه؛ وفي الحالتين أكّد الاتجاه الذي يسلكه فعلًا حقل حساس للامتثال مثل 'do not contact' قبل الاعتماد عليه.
مطابقة الحقول المخصصة تتطلب Data Hub Starter
مطابقات الحقول الافتراضية لا تكلّف شيئًا، لكن ما إن يحتاج حقل مخصص إلى مطابقة حتى يصبح اشتراك Data Hub Starter أو أعلى ثمن الدخول. وبما أن جزءًا كبيرًا من السجل الإقليمي، من رقم الرخصة التجارية إلى تسجيل ضريبة القيمة المضافة واسم الكيان، يميل إلى الإقامة في هذه الحقول المخصصة بالذات، فإن هذه الترقية نادرًا ما تكون اختيارية عمليًا.
الحل البديل: ضع Data Hub Starter في الميزانية الأصلية بدل انتظار اكتشاف لزومه حين تنفد المطابقات المجانية؛ فهو ما يتيح مطابقة الحقول المخصصة أصلًا.
الوحدات المخصصة (Custom Modules) تتطلب معالجة خاصة
الوحدات المخصصة هي القاعدة لا الاستثناء في نشر Sugar المؤسسي، ولا تصل أي منها بمطابقة تلقائية: كل واحدة تحتاج إلى إعداد يدوي أو مزامنة كائنات مخصصة (custom object) على فئة Enterprise تُبنى لها خصيصًا. وحيثما بناها مُكامِل غادر المشروع منذ سنوات، يبدأ عمل الإعداد هذا بمعرفة غاية كل وحدة فعلًا قبل أن يمكن مطابقتها بشيء.
الحل البديل: إما أن تطابق كل وحدة مخصصة مع كائن مخصص في HubSpot على فئة Enterprise، أو تسطّحها إلى كائن قياسي بخصائص مخصصة حيثما تسمح البنية بذلك فعلًا؛ والاختيار يعتمد على ما إذا كانت علاقات الوحدة تستحق الحفظ أو كانت البيانات وحدها هي المهمة.
ترحيل سجل البريد والأنشطة معقد
استيراد CSV لن ينقل المراسلات البريدية ولا سجلات المكالمات ولا سجلات الأنشطة إطلاقًا؛ هذا التاريخ لا ينتقل إلا عبر ترحيل قائم على API مبني لهذا الغرض. خطّط لذلك منذ البداية بدل اكتشاف الأمر في منتصف الطريق، حين يتبين أن جدول البيانات الذي عوّل عليه الجميع لا يستطيع ببساطة استيعابه.
الحل البديل: أداة ترحيل قائمة على API أو خدمة طرف ثالث هي ما ينقل تاريخ الأنشطة بروابطه سليمة، فاحسب ميزانية هذا المسار منذ البداية بدل معاملته خيارًا احتياطيًا.
حملات SugarCRM وTargets لا تُطابَق مباشرة
تُبنى حملة Sugar حول قائمة مستهدفة (target list)، أي جمهور؛ وتُبنى حملة HubSpot حول الأصول التسويقية نفسها. ولأن الاثنتين تصفان شيئين مختلفين جوهريًا، فلا مقابل مباشر تُطابَق إحداهما به مع الأخرى.
الحل البديل: أعد بناء منطق الحملة عبر ثلاث ميزات في HubSpot بدلًا من واحدة: القوائم (lists) والـ workflows وأداة الحملات (campaigns) في HubSpot نفسها، بحيث تصبح كل قائمة مستهدفة في Sugar قائمة نشطة (active) أو ثابتة (static) في HubSpot بشروطها الخاصة لا نسخة مباشرة.
أمر واحد لا يعيد الترحيل بناءه
هذه شيفرة SugarCRM أو منتجه الخاص، ولن ينقلها ترحيل إلى HubSpot: فلا ساعات لها في التقدير. ومع ذلك تحتاج إلى قرار قبل التحويل النهائي، لأنك أنت من يتخلى عن شيء.
Logic Hooks (على مستوى الشيفرة)
كثيرًا ما يكون الـ logic hook في SugarCRM هو الموضع الذي يقيم فيه منطق العمل الحقيقي، ولذلك يحتاج كل واحد منها إلى قراءة وإعادة تنفيذ منفردة بدل افتراض أن workflow سيغطيه. والـ hook الذي ينفَّذ قبل الحفظ (before-save) هو أصعب الحالات: لا مقابل مباشر له في HubSpot، وإعادة إنتاج ما كان يفعله تعني عادةً الجمع بين قاعدة تحقق (validation rule) وworkflow بدل العثور على ميزة واحدة تطابقه.
البنود الـ 35 التي تُعاد بناؤها يدويًا
هذه هي القائمة التي تفرّق بين عرض سعر يصمد وعرض لا يصمد.
البيانات والكائنات
مطابقة تحويل Lead إلى Contact
يبقى Sugar Lead سجلًا منفصلًا عن Contact إلى أن تحوّله خطوة تحويل متعمدة؛ أما HubSpot فلم ترسم هذا الخط قط.
في HubSpot: Contacts with lifecycle stage
لأن HubSpot تحتفظ بسجل Contact واحد لا اثنين، يصبح Sugar Lead والـ Contact الذي تحوّل إليه في النهاية الصف نفسه عند الوصول. قرر كيف ستوفّق بين المكررات والتاريخ خلفها قبل تشغيل الاستيراد: فإصلاح ذلك بعده يعني إعادة معالجة مجموعة البيانات كلها لا تصحيح سجل واحد.
سجل الأنشطة (Activity History)
كل مكالمة واجتماع وبريد سُجّل على سجل Sugar على مدى السنوات التي عملت فيها النسخة.
في HubSpot: Activities on the record timeline
لا ينتقل هذا إلا عبر ترحيل API؛ وتصدير CSV لن ينقله. خصّص له بند ميزانية محددًا بدل افتراض أنه يأتي مجانًا مع بقية البيانات.
الملاحظات مع المرفقات
ملاحظة Sugar مرفق بها ملف، وهو شائع بما يكفي في أي سجل خلفه أوراق حقيقية.
في HubSpot: Notes and attachments
يحتفظ HubSpot بالملاحظة وملفها المرفق كائنين منفصلين لا كائنًا واحدًا، ولذلك يتطلب ترحيل هذا بشكل صحيح مرورين وخطوة بعدهما لإعادة ربط الملف بالملاحظة التي كان تابعًا لها.
بيانات الوحدات المخصصة
أيًا كانت السجلات التي تقيم داخل وحدات Sugar المخصصة، وكثيرًا ما تكون الجزء من النسخة الذي يحمل أكبر قدر من البنية الخاصة بالعمل وأقل قدر من التوثيق.
في HubSpot: Custom objects
يتوقف ما إذا كان بوسع HubSpot أصلًا استقبالها كائنات مخصصة على فئة الاشتراك، فتأكد مما يُشترى فعلًا قبل تصميم المطابقة؛ وإذا أخطأت هذا الترتيب انهارت البيانات إلى خصائص عادية بدل الكائنات المهيكلة التي تحتاجها.
قوائم الاستهداف في الحملات
قوائم الجمهور الكامنة وراء كل حملة في Sugar، أي القائمة الفعلية لمن جرى استهدافهم لا أصل الحملة نفسه.
في HubSpot: Static and active lists
قائمة الاستهداف المبنية على استعلام محفوظ قاعدة تستمر في التقييم لا عضوية ثابتة، واستيرادها يلتقط لحظة واحدة فقط. أعد بناء المعايير الكامنة في HubSpot لا القائمة المجمّدة، وإلا توقف الجمهور عن التحديث يوم وصوله.
مرفقات المستندات والملفات
الملفات المرفقة بالسجلات عبر كل وحدة في النسخة، ومنها نسخ الرخص التجارية والعقود الموقعة في الحسابات الإقليمية.
في HubSpot: Attachments on records
خطّط لمرور API مستقل بعد وصول السجلات نفسها إلى HubSpot، إذ لا تنتقل المرفقات مع ترحيل السجل من تلقاء نفسها.
بيانات العلاقات ما وراء الروابط الأساسية
كل رابط من نوع «متعدد إلى متعدد» تحتفظ به Sugar بين السجلات، ما وراء العلاقة الواحدة التي تحفظها المزامنة الأساسية فعلًا.
في HubSpot: Secondary associations with labels
يتوقف ما إذا كانت هذه الروابط تحمل علاقات ذات تسميات (labelled associations) أصلًا على فئة الاشتراك؛ وبدون تلك الفئة تنجو العلاقة الأساسية الواحدة فقط من النقل، ويظهر أثر ذلك أشد ما يكون في تسلسل الحسابات حيث تعتمد الشركة القابضة وكياناتها التشغيلية على أكثر من رابط لتبقى متصلة.
الأتمتة
تعريفات SugarBPM Workflow
يحمل SugarBPM، محرك سير العمل المتقدم في Sugar، كل تعريف عملية بُني داخله، ولا ينتقل أي من هذا المنطق إلى أداة workflows في HubSpot تلقائيًا.
في HubSpot: Workflows
يفكر SugarBPM بلغة الحالات والبوابات (states and gateways)؛ وتفكر workflows في HubSpot بلغة التسجيل والإجراء (enrolment and action)، وهذا شكل مختلف من الأتمتة لا أبسط منه. وتعريف SugarBPM معقد فعلًا يُعاد تصميمه من الأساس لا يُترجم سطرًا بسطر، وإعادة التصميم هذه وقت تصميم يستحق إدخاله في نطاق المشروع منذ البداية، خصوصًا حين لا يبقى في الفريق من بنى العملية الأصلية.
تدفقات العمل من Process Author
توجّه تدفقات Process Author عملية عمل عبر عدة خطوات، لكل منها مشاركوها ونقاط قرارها في الطريق.
في HubSpot: Workflows plus tasks, or an external process tool
حيثما تعتمد العملية على قرار بشري يُتخذ ثم يُسلَّم إلى الشخص التالي، فقد لا تستطيع أداة workflows في HubSpot وحدها حملها من البداية إلى النهاية. أثِر هذه الفجوة قبل التوقيع لا في منتصف البناء، حين يكون غياب خطوة اعتماد اكتشافًا أغلى بكثير.
قواعد إسناد الـ Leads وتوجيهها
قواعد تحدد المالك الذي يُسند إليه السجل الجديد لحظة وصوله.
في HubSpot: Workflow rotation actions
جهّز المستخدمين والفرق في HubSpot قبل كتابة أي قاعدة توجيه، ثم اختبر التوزيع على سجلات حقيقية بدل الوثوق بالمنطق على الورق.
محفزات إشعارات البريد الإلكتروني
من يُبلَّغ فعلًا لحظة يتغير سجل معين.
في HubSpot: Notification settings and workflow internal emails
يقسم HubSpot هذا بين إعدادين منفصلين بدل إبقائه في مكان واحد، فتحقق من الاثنين قبل افتراض اكتمال إعادة البناء؛ فالتوقف عند الأول لا يعيد بناء سوى نصف ما كان Sugar يفعله.
الإجراءات المجدولة والتذكيرات
إجراءات تُنفَّذ وفق جدول خاص بها، دون حاجة إلى تغيير في سجل ليطلقها.
في HubSpot: Date-based workflow enrolment and delays
اختبر التوقيت على سجلات حقيقية قبل الوثوق به، لأن المنصتين تحسبان التأخير بطريقتين مختلفتين بما يكفي لأن يقع تذكير بُني لينفَّذ في اليوم الثالث في موضع آخر تمامًا.
تدفقات الموافقة (Approval Workflows)
خطوات لا تسمح للسجل بالتقدم إلى أن يعتمده أحد.
في HubSpot: Workflow approval actions, or an external approval tool
دعم الموافقات في HubSpot أضيق مما كان يقدمه Sugar، فتأكد تحديدًا مما يحتاج فعلًا إلى اعتماد، خصم أو رد على مناقصة أو بند عقد، قبل الوعد بإعادة بناء مطابقة قد لا يستطيع HubSpot وحده تقديمها.
التقارير
التقارير المخصصة والمرشحات المحفوظة
كل تعريف تقرير ومرشح محفوظ بُني على بيانات Sugar على مدى استخدام النسخة.
في HubSpot: Custom reports and saved views
أعد بناء كل واحد انطلاقًا من السؤال الذي كان يجيب عنه فعلًا بدل نسخ تخطيطه القديم؛ فالتقرير الذي يُبقى بدافع العادة وحدها نادرًا ما يستحق مكانه مرة ثانية.
إعدادات لوحات المتابعة (Dashboards)
أي تخطيطات للوحات المتابعة حُفظت وشورِكت عبر نسخة Sugar.
في HubSpot: Dashboards
ابنِ اللوحات بعد وجود التقارير الأساسية في HubSpot لا قبلها؛ فاللوحة المبنية قبل تقاريرها لوحة تُعاد بناؤها مرة أخرى.
تقارير بنود الإيرادات (Line Items)
تقارير مبنية للعمل على مستوى البند الفردي (line item) بدل التوقف عند الصفقة ككل.
في HubSpot: Line item reporting
يعتمد هذا كليًا على أن يكون كتالوج المنتجات وبنوده قد استُورد بنظافة، فرتّب هذا العمل بعد استقرار الكتالوج لا بالتوازي معه.
إعدادات التوقعات (Forecast)
أي منطق كان Sugar يستخدمه لتجميع الفرص الفردية في رقم توقع واحد.
في HubSpot: Forecasting
عامل هذا مهمة إعداد يجب أن تتم قبل التقارير، واتفق على التعريف الفعلي للتجميع مع من يعتمد الرقم النهائي، لأن سلوك التجميع في HubSpot لا يطابق سلوك Sugar تمامًا.
توزيع التقارير المجدول
أي تقارير كانت تُرسل بالبريد وفق جدول إلى قائمة ثابتة من المستلمين.
في HubSpot: Scheduled dashboard emails
يجدول HubSpot لوحة متابعة كاملة للإرسال لا تقريرًا منفردًا، ولذلك قد تحتاج التجميعات القديمة إلى إعادة ترتيب حول ما يُفترض أن يراه كل مستلم فعلًا بدل افتراض انتقالها تقريرًا بتقرير.
إعدادات المبيعات والتسويق
نماذج تقييم الـ Leads (Lead Scoring)
أي نموذج كان Sugar يستخدمه لترتيب Lead وارد مقابل البقية.
في HubSpot: Score properties
يُبنى هذا من جديد من الصفر، على الإشارات التي يسجلها HubSpot فعلًا لا تلك التي صادف أن تتبعها Sugar، ومنها حضور المعارض والمؤتمرات والاستفسارات الواردة عبر WhatsApp والإحالة داخل المجموعة، وهي الإشارات التي تستحق وزنًا في هذه السوق.
قوالب البريد والحملات
كل قالب يؤدي حاليًا مهمتين في الإرسال اليدوي والحملات الآلية معًا.
في HubSpot: Email templates and marketing email templates
يعامل HubSpot قوالب المبيعات وقوالب التسويق نوعين منفصلين من الكائنات، فصنّف كل قالب Sugar في النوع الصحيح قبل بدء إعادة البناء؛ وفريق ثنائي اللغة يستفيد خصوصًا من هذا التصنيف المتعمد، لأن قالب مبيعات بالعربية ونظيره التسويقي نادرًا ما يشتركان في متطلبات التخطيط نفسها.
مراحل الـ Pipeline وعمليات المبيعات
مراحل المبيعات التي كان Sugar يديرها وأي عملية كانت خلف كل مرحلة.
في HubSpot: Deal pipelines and stages
ابنِ هذا قبل أي شيء آخر في إعداد المبيعات، لأن كل ما يأتي بعده، من التقييم والتوقعات والتقارير، يعتمد على أن يكون الـ pipeline صحيحًا أصلًا.
نماذج Web-to-lead
كل نموذج ويب ترسل ردوده حاليًا مباشرة إلى Sugar.
في HubSpot: Forms
استبدل كل رمز تضمين (embed code) في يوم التحويل النهائي نفسه، وعلى النسختين العربية والإنجليزية للموقع إن كانتا تعملان منفصلتين، وإلا استمرت الـ leads في الوصول بصمت إلى نظام لم يعد أحد يراقبه.
تسلسلات المبيعات وحملات Drip
أي تسلسل متابعة متعدد نقاط الاتصال كان يُدار مباشرة من Sugar.
في HubSpot: Sequences and workflows
قرر حملةً حملةً هل مكانها في HubSpot تسلسل مبيعات (sales sequence) أو إرسالًا تسويقيًا، لأن لكل منهما قواعد موافقة مختلفة، وخطأ هذا التصنيف مسألة امتثال لا مسألة تسمية.
إعدادات الحصص (Quota) والتوقعات
أي هدف حُدد لكل مندوب عبر كل فترة كان Sugar يتتبعها.
في HubSpot: Goals
يُضبط هذا مستخدمًا بمستخدم لا مرة واحدة للفريق كله، فعامله مهمة متكررة تُجدول لا خطوة إعداد واحدة تُشطب.
كتالوج المنتجات وقوائم الأسعار (Price Books)
كتالوج المنتجات وقوائم الأسعار التي بُنيت لتجاور الكتالوج.
في HubSpot: Products and line items
يعمل HubSpot من مكتبة منتجات واحدة لا من عدة قوائم أسعار منفصلة، ولذلك حيثما استخدم Sugar قوائم الأسعار لاحتواء شرائح مختلفة من العملاء، فإن هذا المنطق يجب أن ينتقل إلى تسعير البنود (line-item pricing) أو أداة عروض أسعار مخصصة بدلًا من ذلك، وهو قرار تصميم حقيقي لكتالوج مسعَّر أصلًا بحسب السوق بأكثر من عملة خليجية.
المستخدمون والصلاحيات
أدوار المستخدمين والتحكم في الوصول
كل دور وإعداد ACL كان يحدد من داخل Sugar يستطيع رؤية ماذا ولمس ماذا.
في HubSpot: Users and permission sets
تذهب ACLs في Sugar أبعد بكثير في دقتها مما ستذهب إليه مجموعات الصلاحيات (permission sets) في HubSpot، فطابِق ما كانت كل قاعدة تسعى إلى تحقيقه فعلًا بدل محاولة إعادة إنتاج المصفوفة خلية بخلية. وأكّد مباشرة مع صاحب القرار أي الضوابط غير قابلة للتفاوض فعلًا، ومن الأسئلة الجديرة بالطرح صراحةً هل يرى مركز دبي سجلات كيان سعودي، قبل بناء مجموعات الصلاحيات.
رؤية السجلات على مستوى الفريق
أي قاعدة كانت تُبقي مجموعة معينة من السجلات مرئية لفريق محدد وحده.
في HubSpot: Teams and record access settings
يرسم HubSpot هذه الخطوط بشكل مختلف عن Sugar، فتأكد مما يحتاج إلى الإخفاء فعلًا قبل إعادة إنتاج قاعدة قديمة بدافع العادة؛ فحدّ لا يتذكر أحد سببه جدير بأن يُسأل عنه لا أن يُعاد بناؤه كما هو.
إدارة المناطق (Territory Management)
بنية المناطق التي كان Sugar يحتفظ بها وطريقة إسناد السجلات عبرها.
في HubSpot: Properties plus workflow-based assignment
لا يملك HubSpot كائن مناطق مخصصًا يستقبل هذا، فصمّم الخاصية التي ستقوم مقامه أولًا، ولا تكتب قواعد الإسناد إلا بعد وجود تلك الخاصية؛ وفي مجموعة تغطي عدة أسواق خليجية تكون هذه الخاصية أيضًا لحظة تقرير هل تتبع المنطقة الدولة أم الكيان القانوني أم اللغة.
إعدادات مجموعات الأمان
أي مجموعات أمان رُصّت فوق بعضها للتحكم في الوصول عبر وحدات Sugar.
في HubSpot: Teams and permission sets
كثيرًا ما تُرمِّز مجموعة الأمان قاعدة لا يتذكر أحد من الفريق الحالي أنه وافق عليها أصلًا، خصوصًا بعد أن يغادر من أعدّها. اجعل الترحيل لحظة تسأل فيها ماذا تحمي كل واحدة فعلًا بدل حملها إلى الأمام دون فحص.
إعدادات النظام الإدارية
أي إعدادات على مستوى النسخة كان مشرفو Sugar يحتفظون بها، الإعدادات التي لا يفكر فيها أحد إلى أن تغيب.
في HubSpot: Account settings
يُعاد ضبط معظم هذا يدويًا لا ترحيلًا. والعملة والمنطقة الزمنية والسنة المالية هي الثلاثة التي تسبب أخطاء ظاهرة لحظة إغفالها، وتستحق أن تُفحص مقابل كل كيان يديره العمل بدل افتراض أنها إعداد واحد للمجموعة كلها.
التكاملات
اتصالات التطبيقات من أطراف ثالثة
كل موصل محاسبة وERP واتصالات هاتفية موصول حاليًا بـ Sugar، من نوع التكاملات التي تتراكم في نسخة مستضافة ذاتيًا على مر السنين.
في HubSpot: App Marketplace integrations
اتصال ERP خصوصًا نادرًا ما يكون له مقابل جاهز ينتظر في جانب HubSpot. أحصِ كل واحد منها مبكرًا لا متأخرًا، لأن أحدها عادةً ما يتبين أنه أصعب جزء في المشروع كله.
Logic Hooks (الخطافات البرمجية)
شيفرة PHP مخصصة كُتبت لتنفَّذ تلقائيًا كلما وقع حدث معين في Sugar، وهي من نوع الـ logic hooks التي تتراكم في نسخة مستضافة ذاتيًا ويرجَّح أن يحملها مُكامِل غادر.
في HubSpot: Workflow custom code actions, or an external service
هذه شيفرة حقيقية قائمة على المنصة المصدر لا إعداد يُبدَّل. اقرأ كل hook قبل تسعير جدول زمني، لأنه كثيرًا ما يكون المكان الوحيد الذي دُوّنت فيه قاعدة عمل أصلًا، وخصوصًا بعد أن يكون من كتبها قد انتقل ولم يترك شيئًا آخر.
تكاملات API وWebhooks
شيفرة مخصصة وwebhooks صادرة بُنيت للتحدث مباشرة مع API الخاصة بـ Sugar، أينما كانت تقيم.
في HubSpot: HubSpot APIs and workflow webhook actions
يحتاج كل ذلك إلى إعادة كتابة على نموذج كائنات مختلف، والنقاط الطرفية (endpoints) في الجهة المستقبِلة تحتاج عادةً إلى تغييراتها الخاصة أيضًا، لا الشيفرة التي تستدعيها وحدها.
مزامنة التقويم
أي اتصال تقويم، Google أو Outlook، ربطه كل شخص بحسابه في Sugar.
في HubSpot: Calendar integration and the meetings tool
يُعاد وصل هذا شخصًا بشخص لا مرة واحدة للحساب كله، فعامله مهمة طرح (rollout) مرتبطة بعدد الأشخاص لا خطوة إعداد واحدة.
إضافات Marketplace وملحقاتها
أي امتدادات من أطراف ثالثة جرى تثبيتها مباشرة في نسخة Sugar على مدى عمرها.
في HubSpot: App Marketplace integrations, or no equivalent
قد تمتد إضافة Sugar بالتطبيق نفسه بطريقة لا تسمح بها منصة HubSpot ببساطة، فبعضها لا بديل ينتظره في أي مكان. اعرف ذلك مبكرًا: فأن تعلم أثناء تحديد النطاق أن إضافة لا يمكن استنساخها أرخص بكثير من أن تكون قد وعدت العمل بانتقالها.
التسلسل
زامِن أولًا، ثم رحّل
الترتيب هو المضمون هنا. هذه الخطوات سلسلة اعتماد متبادل، وتنفيذها خارج التسلسل طريقة موثقة يفشل بها هذا النوع من الترحيل.
- 1
التدقيق (Audit)
احصر كل وحدة (module) في SugarCRM وكل حقل مخصص وworkflow وتكامل وصلاحية مستخدم قبل أن تقرر أي شيء آخر، وتعامل بعناية حقيقية مع النسخة المستضافة ذاتيًا أو داخل المؤسسة (on-premise)، لأن سنوات من التخصيص بناها مُكامِل قد لا يمكن الوصول إليه أرض مألوفة هنا، ومعرفة غاية كل وحدة فعلًا تسبق تقرير مصيرها
- 2
تخطيط مطابقة Lead وContact
قرر، قبل أن ينتقل سجل واحد، كيف يندمج كائنا Lead وContact المنفصلان في SugarCRM في Contact واحد موحد في HubSpot، فهذا هو قرار التصميم الذي يقوم عليه كل شيء آخر في الترحيل
- 3
تنظيف البيانات
أزل التكرار من السجلات، واحذف ما هو غير نشط فعلًا، ووحّد قيم الحقول، مع تخصيص مرور مستقل لقوائم الاختيار (picklists) التي تراكمت بالعربية والإنجليزية معًا بدل افتراض أن مدخلات إحدى اللغتين ستطابق الأخرى تلقائيًا
- 4
إعداد HubSpot
أنشئ الخصائص المخصصة ومراحل الـ pipeline ومطابقات مراحل دورة الحياة (lifecycle stage) قبل السماح لأي سجل بالوصول، حتى تكون الوجهة جاهزة بدل أن تُجمَّع تحت البيانات وهي تصل
- 5
تثبيت التكامل
أدخل تطبيق Data Sync من HubSpot وأعدّ مزامنة حقيقية في الاتجاهين لـ Contacts وCompanies وDeals، بدل الاعتماد على موصل SugarCRM الأبطأ ذي الاتجاه الواحد
- 6
ترحيل سجل الأنشطة
انقل المكالمات والاجتماعات والملاحظات والرسائل البريدية عبر API أو أداة طرف ثالث، لأن شيئًا منها لا ينجو من تصدير CSV عادي
- 7
إعادة بناء الأتمتة
أعد إنشاء كل workflow وقاعدة أتمتة مباشرة في HubSpot، مستفيدًا من إعادة تصميم SugarBPM لتدوين سلسلة الموافقات التي يعمل العمل عليها فعلًا بدل إعادة إنتاج ما صادف أن أتمتته Sugar
- 8
إعادة إنشاء التقارير
أعد بناء التقارير ولوحات المتابعة وإعدادات التوقعات انطلاقًا من الأسئلة التي كانت تجيب عنها فعلًا، لا من تخطيطاتها القديمة
- 9
إعادة ضبط التكاملات
أعد وصل كل تطبيق من أطراف ثالثة، من المحاسبة وERP إلى الاتصالات الهاتفية، وعامل اتصال ERP بوصفه الأرجح أن يحتاج إلى عمل حقيقي لا إلى استبدال سريع
- 10
التدريب والتحويل النهائي
درّب الفريق على HubSpot تدريبًا جيدًا، وشغّل النظامين بالتوازي لفترة حيثما يسمح الجدول الزمني، واختر موعد التحويل النهائي مقابل التقويم الهجري إلى جانب الميلادي حتى لا يقع في الأسبوع الذي يسبق العيد
عادةً من 4-8 أسابيع من البداية إلى النهاية، بحسب مقدار ما يُستخدم فعلًا من إعدادات المصدر.
مقدّر الجهد
ما حجم هذا الترحيل؟
مجموعة أسئلة قليلة، دون حاجة إلى تسجيل. تأتي النطاقات من البحث أعلاه: لكل ميزة طابقناها رقم جهد، وهذه الأداة تجمع الميزات التي تنطبق على نسختك.
الجهد التقديري
أجب عن سؤالين ليظهر هنا نطاق الساعات.
مبني على أبحاثنا حول 49 ميزة في SugarCRM. إنه نطاق تقديري وليس عرض سعر.
نطاق للتخطيط وليس عرض سعر. وهو جهد التنفيذ فقط، دون بند لإدارة المشروع. وأكثر ما يحرّكه عمليًا هو جودة البيانات.
ما الذي يسوء في أغلب الأحيان
الإخفاقات التي تتكرر مرة بعد مرة، بترتيب ظهورها تقريبًا.
يخلق كائنا Lead وContact المنفصلان في SugarCRM خطر تكرار حقيقيًا لحظة انهيارهما في Contact واحد في HubSpot، فطابِق مراحل دورة الحياة بعناية حقيقية بدل ترك المنطق الافتراضي يقرر
يخلق كائنا Lead وContact المنفصلان في SugarCRM خطر تكرار حقيقيًا لحظة انهيارهما في Contact واحد في HubSpot، فطابِق مراحل دورة الحياة بعناية حقيقية بدل ترك المنطق الافتراضي يقرر
تكامل HubSpot الأصلي الذي توفره SugarCRM بطيء وغير موثوق عمليًا، إذ يفحص كل سجل يدويًا بحثًا عن تطابق، فاستخدم تطبيق Data Sync من HubSpot بدلًا من الاتكال عليه
تكامل HubSpot الأصلي الذي توفره SugarCRM بطيء وغير موثوق عمليًا، إذ يفحص كل سجل يدويًا بحثًا عن تطابق، فاستخدم تطبيق Data Sync من HubSpot بدلًا من الاتكال عليه
الوحدات المخصصة، وهي معيار في نشر Sugar المؤسسي وكثيرًا ما تكون أقل أجزائه توثيقًا، تحتاج إلى تخطيط ترحيل خاص بها بدل إدراجها في خطة البيانات العامة
الوحدات المخصصة، وهي معيار في نشر Sugar المؤسسي وكثيرًا ما تكون أقل أجزائه توثيقًا، تحتاج إلى تخطيط ترحيل خاص بها بدل إدراجها في خطة البيانات العامة
لا شيء في SugarBPM workflow يمكن تصديره؛ ويجب إعادة إنشاء كل واحد منها يدويًا في HubSpot، وهذا وقت تصميم بقدر ما هو وقت إعداد
لا شيء في SugarBPM workflow يمكن تصديره؛ ويجب إعادة إنشاء كل واحد منها يدويًا في HubSpot، وهذا وقت تصميم بقدر ما هو وقت إعداد
بنية الحملات القائمة على الجمهور في SugarCRM تختلف عن بنية HubSpot القائمة على الأصول بما يكفي ليحتاج التفكير في استراتيجية الحملات إلى مراجعة حقيقية لا إعادة بناء مباشرة
بنية الحملات القائمة على الجمهور في SugarCRM تختلف عن بنية HubSpot القائمة على الأصول بما يكفي ليحتاج التفكير في استراتيجية الحملات إلى مراجعة حقيقية لا إعادة بناء مباشرة
مرشحات التقارير في Sugar وكل تقرير مخصص بُني عليها يجب إعادة بنائها من الصفر، إذ لا تنتقل المرشحات ولا منطق التقرير
مرشحات التقارير في Sugar وكل تقرير مخصص بُني عليها يجب إعادة بنائها من الصفر، إذ لا تنتقل المرشحات ولا منطق التقرير
تنظيف البيانات ليس اختياريًا هنا
قاعدة بيانات Sugar التي ظلت تعمل لسنوات، وكثيرًا ما تكون مستضافة ذاتيًا ونادرًا ما تُدقَّق وفق جدول، تميل إلى حمل ثقل حقيقي من السجلات المكررة والقديمة المتراكمة التي ينبغي تنظيفها قبل الترحيل لا بعده
الأسئلة
SugarCRM إلى HubSpot: أسئلة وأجوبة
نعم. مزامنة بيانات في الاتجاهين تغطي 8 كائنات. ما لن تفعله هو إعادة بناء إعداداتك: وهذه هي البنود الـ 35 أدناه.
عادةً من 4-8 أسابيع. ويحدد التعقيد عمق الأتمتة والتقارير لا عدد السجلات: فالموصل ينقل السجلات، ولذلك لا تطيل قاعدة بيانات كبيرة بحد ذاتها الجدول الزمني.
من بين 49 ميزة طابقناها، تنتقل 33 ميزة (67%) مباشرة وتُطابَق 16 ميزة (33%) جزئيًا، أي يضيع شيء منها أو يُعاد تشكيله في الطريق. و0 ميزة بلا مقابل في HubSpot في أي فئة، وهذا يستحق طرحه قبل التوقيع لا بعده.
يجب إعادة بناء 35 بندًا يدويًا، و7 قيود موثقة لا يُظهرها الموصل إطلاقًا. القائمتان في هذه الصفحة كاملتين لمن يحدد نطاق العمل.
تعمل المطابقات الافتراضية على الفئة المجانية؛ وأي شيء مخصص يحتاج Data Hub Starter أو أعلى. وجانب Sugar من التكامل الأصلي هو الجزء الذي يستحق تخصيص وقت له أيًا كانت الفئة، لأنه قد يحتاج إلى مطور لإعداده لا إلى مشرف يفعّله، خصوصًا في النسخ المستضافة ذاتيًا (self-hosted).
لا. بند واحد (1) في هذه الصفحة هو شيفرة SugarCRM أو منتجه الخاص، ولا ينقله ترحيل HubSpot ولا ساعات له في أي تقدير يُعطى لك. ومع ذلك يحتاج إلى قرار قبل التحويل النهائي، لأنك أنت من يتخلى عن شيء.
في اتجاه واحد فقط. المزامنة هنا ليست في الاتجاهين، فتشغيل النظامين معًا يعني اختيار نظام السجل المرجعي (system of record) منذ البداية وقبول انحراف البيانات في الآخر.
هل أنت مستعد للبدء؟
خطّط لعملية الترحيل
أخبرنا بالمنصة التي تنتقل منها، وحجم التخصيص فيها، والموعد الذي تحتاج فيه إلى العمل على HubSpot. وسنوضح لك ما ينتقل مباشرة، وما يحتاج إلى إعادة بناء، والمدة التي يستغرقها الانتقال فعلياً.