قائمة التحقق لعملية ترحيل Hyvä: 47 عنصرًا قبل أن تبدأ
مشاريع ترحيل Hyvä التي تستغرق وقتًا طويلاً أو تتجاوز الميزانية تعود دائمًا تقريبًا إلى شيء تم تفويته أثناء تحديد النطاق. هذه القائمة تحتوي على 47 عنصرًا نقوم بمراجعتها مع كل تاجر خلال مرحلة ما قبل الإطلاق. يستغرق العمل عليها مرة واحدة من 2 إلى 3 ساعات ويمنع 90% من المفاجآت أثناء المشروع.
استخدمها قبل توقيع نطاق ترحيل Hyvä. خذها إلى أي وكالة تفكر فيها وراجعها معًا.
القسم أ: بيئة Magento (العناصر 1–8)
1. تأكيد إصدار Magento (على سبيل المثال، Magento Open Source 2.4.6، Adobe Commerce 2.4.7). تدعم Hyvä إصدارات محددة؛ إذا كنت تستخدم إصدارًا قديمًا، خطط لترقية Magento أولاً.
2. إصدار PHP مدعوم من Hyvä. تدعم Hyvä عادةً PHP 8.1+ حسب إصدار Magento. تأكد من أن استضافتك تتطابق.
3. بيئة الاستضافة جاهزة للاختبار. بيئة اختبار منفصلة (تتطابق مع تكوين الإنتاج + بيانات حديثة) أمر لا يمكن التفاوض عليه. تحدث أعمال الترحيل هنا قبل الانتقال.
4. تحديث بيانات الإنتاج مؤخرًا للاختبار. بيانات الاختبار التي تزيد عن 30 يومًا ستظهر اختلافات مقارنة بالإنتاج في UAT. قم بتحديثها قبل بدء العمل.
5. عمل مصادقة Composer لـ Magento + البائعين الخاصين. تأكد من أن composer install يعمل بشكل سليم على بيئة الاختبار. مشاكل المصادقة أثناء المشروع تعيق النشر.
6. مساحة كافية على القرص + الذاكرة في بيئة الاختبار لتثبيت Hyvä. الأصول المجمعة لـ Hyvä تضيف إلى استخدام القرص؛ تحقق من أن بيئة الاختبار يمكنها التعامل معها.
7. إجراء النسخ الاحتياطي لقاعدة البيانات موثق. تأكد من أنه يمكنك التراجع عن قاعدة البيانات إذا حدث أي شيء كارثي أثناء الانتقال.
8. اختبار سير عمل وضع الصيانة. تأكد من أن تمكين/تعطيل وضع الصيانة يعمل كما هو متوقع، فهذا هو الآلية في يوم الانتقال.
القسم ب: جرد الإضافات (العناصر 9–18)
9. قائمة كاملة بالإضافات موثقة. اسم البائع + اسم الإضافة + الإصدار + حالة الترخيص لكل إضافة مدفوعة. استخرج من composer.json + composer.lock.
10. الإضافات المثبتة عبر ZIP محددة بشكل منفصل. أي شيء في app/code/* لم يتم تسليمه عبر Composer. غالبًا ما تكون الأكثر تعقيدًا في الترحيل.
11. الإضافات المخصصة داخليًا محددة. أي شيء كتبته فريق التطوير السابق الخاص بك والذي يمس الواجهة الأمامية.
12. تم التحقق من كل إضافة مقابل compat.hyva.io. تم ملاحظة الحالة: متوافقة (توافق البائع) / حل بديل (توافق المجتمع) / غير متوافقة / غير معروفة.
13. تم التحقق من إصدارات وحدات توافق البائع. قد لا يقوم البائع الذي يرسل توافق Hyvä لإصدار الإضافة الحالي بذلك لإصدارك القديم. تحقق لكل إضافة.
14. تم تحديد الإضافات التي يجب "تخطيها بدلاً من ترحيلها". الإضافات المهجورة، الإضافات الزائدة، الإضافات المقررة للاستبدال، تم وضع علامة عليها حتى لا ندفع مقابل التوافق الذي لن نستخدمه.
15. تأكيد صلاحية الترخيص لكل إضافة مدفوعة. يحتاج تثبيت Composer إلى تراخيص صالحة؛ التراخيص المنتهية تعيق النشر.
16. تم وضع علامات على الإضافات التي تتعلق بعملية الدفع لمزيد من ضمان الجودة. الدفع، الاحتيال، الشحن، بطاقات الهدايا، رصيد المتجر، تحتاج جميعها إلى اختبار كامل لتدفق الطلب.
17. تم جرد تعديلات التصميم المخصصة. أي شيء قام فريق التطوير السابق بتخصيصه في تصميم Luma الذي يحتاج إلى تكراره تحت Hyvä.
18. تم ملاحظة الاعتماد على السلاسل السحرية / مفاتيح الأحداث. تعتمد بعض الإضافات على أسماء أحداث محددة أو سلاسل سحرية، يجب أن تنتقل هذه في وحدات توافق Hyvä.
القسم ج: المحتوى + هيكل URL (العناصر 19–26)
19. هيكل URL موثق. كل URL لصفحة PDP، PLP، CMS موثق. تم التحقق من أن URLs التي لن تتغير.
20. تم تحديد URLs التي ستتغير. أي شيء يتغير يحتاج إلى إعادة توجيه 301 في وقت الانتقال.
21. تم نسخ جدول إعادة كتابة URL. جدول url_rewrite في Magento حرج لتحسين محركات البحث؛ قم بنسخه قبل الانتقال.
22. تم التحقق من البيانات المنظمة (المنتج، العرض، فتحة الخبز، صفحة الأسئلة الشائعة) على الموقع الحالي. ما هو موجود الآن يحتاج إلى الانتقال إلى Hyvä.
23. تم توثيق ترميز Schema.org الموجود على PDP. تحديدًا: المنتج، العرض، AggregateRating، المراجعة، صفحة الأسئلة الشائعة. تأكد من أن جميعها تنتقل.
24. تم جرد محتوى CMS. الصفحات الثابتة، كتل CMS، اللافتات، كتل المحتوى الديناميكية، جميعها تحتاج إلى نظيراتها في Hyvä.
25. تم تأكيد بيانات التعريف SEO لكل نوع صفحة. علامات العنوان، أوصاف التعريف، علامات كانونيكالية، hreflang للغات المتعددة.
26. تم توثيق الحالة الحالية لخريطة الموقع وrobots.txt. الانتقال لا يغير هذه ولكن مراجعتها هو وقت جيد.
القسم د: خط الأساس للأداء (العناصر 27–32)
27. تم تسجيل درجة أداء Mobile Lighthouse لصفحات PDP، PLP، البحث، السلة، الدفع. هذه هي خط الأساس قبل قياس التحسين.
28. تم تسجيل حالة Core Web Vitals من Search Console. الحالة الحالية جيدة/تحتاج إلى تحسين/سيئة لكل مجموعة URL.
29. تم قياس وزن الصفحة الحالي. وزن HTML، JS، CSS، الصور لكل نوع صفحة رئيسية.
30. جرد علامات الطرف الثالث. علامات GTM، نصوص التحليلات، أدوات الدردشة، بكسلات التسويق، أي شيء يتم تحميله من نطاقات غير تابعة للطرف الأول.
31. تم تسجيل معدل التحويل الحالي للهواتف المحمولة. تحديدًا: معدل إضافة السلة للهواتف المحمولة ومعدل إتمام الدفع للهواتف المحمولة. الأرقام بعد ذلك هي كيف ستقيس العائد على الاستثمار.
32. تم تسجيل معدل التحويل الحالي لسطح المكتب. كمرجع؛ الزيادة ستكون أقل على سطح المكتب مقارنة بالهواتف المحمولة.
القسم هـ: التصميم + تجربة المستخدم (العناصر 33–38)
33. تأكيد نية التصميم: إعادة بناء وفية مقابل إعادة العلامة التجارية مقابل اتجاه جديد. هذا هو أكبر خطر في تغيير نطاق المشروع؛ قم بتثبيته أثناء تحديد النطاق.
34. توثيق رموز العلامة التجارية. الألوان، الطباعة، المسافات، أنصاف قطر الحدود. هذه تغذي تكوين Tailwind.
35. توقعات مكتبة المكونات محددة. أنماط الأزرار، أنماط النماذج، أنماط البطاقات، هل توجد؟ تحتاج إلى تصميم؟ استخدام الافتراضات الخاصة بـ Hyvä؟
36. جرد كتل عرض PDP. المنتجات ذات الصلة، التي تمت مشاهدتها مؤخرًا، المبيعات الإضافية، المبيعات المتقاطعة، Accordion الأسئلة الشائعة، المراجعات، جميعها تنتقل؟
37. تأكيد متطلبات قسم حساب العميل. حساب Magento الافتراضي أو المخصص؟ الاشتراكات، بطاقات الهدايا، المرتجعات؟
38. ملاحظات متطلبات تجربة المستخدم المحددة للهواتف المحمولة. إضافة إلى السلة الثابتة، سلة التسوق الصغيرة للهواتف المحمولة، سلوك الفلترة للهواتف المحمولة.
القسم و: ميزات B2B / Adobe Commerce (العناصر 39–43)
(تجاوز هذا القسم إذا كانت Magento Open Source B2C.)
39. توثيق ميزات B2B المستخدمة. حسابات الشركات، الكتالوجات المشتركة، التسعير المحدد للعملاء، الاقتباسات، قوائم الطلبات، سير عمل الموافقة، جميعها تحتاج إلى إعادة تصميم.
40. تأكيد رؤية كتالوجات العملاء المقسمة. أي الشرائح ترى أي منتجات / فئات؟
41. توثيق منطق التسعير المحدد للعملاء. مستويات التسعير، تسعير العقود، تخفيضات الكميات، جميعها تحتاج إلى العرض بشكل صحيح لكل عميل مسجل.
42. توثيق حدود سير عمل الموافقة. أي الطلبات تحتاج إلى موافقة، من يوافق، كيف يعمل الإشعار.
43. ملاحظات سمات PDP المحددة لـ B2B. أوراق البيانات، الشهادات، أوقات التسليم، تسعير التعبئة الكبيرة.
القسم ز: أصحاب المصلحة + إدارة المشروع (العناصر 44–47)
44. حجز نوافذ مراجعة أصحاب المصلحة. تحتاج أسبوع UAT إلى تقويم فريقك. احجزها قبل بدء العمل.
45. تأكيد نافذة الانتقال. عطلة نهاية الأسبوع خارج أوقات الذروة، لا أحداث مبيعات، لا حملات تسويقية تتنافس على الحركة.
46. تأكيد مورد مراقبة ما بعد الإطلاق. شخص من جانبك متاح لمدة 72 ساعة بعد الانتقال لالتقاط المشكلات.
47. تأكيد سلطة التوقيع. من لديه السلطة لتوقيع تغييرات النطاق، إكمال UAT، الانتقال للذهاب/عدم الذهاب؟ يفضل أن يكون شخص واحد مسمى.
ماذا تفعل بهذه القائمة
قم بمراجعتها قبل طلب عروض أسعار تحديد النطاق. كلما زادت العناصر التي يمكنك الإجابة عليها "نعم / موثقة / مؤكدة" قبل التحدث إلى الوكالات، كلما كانت عملية تحديد النطاق أسرع وأرخص.
خذها إلى قائمة وكالات Hyvä المختصرة. اجعلهم يعملون عليها معك. الوكالات التي تتفاعل بشكل شامل مع قائمة التحقق تظهر أنها تفهم الترحيل؛ الوكالات التي تتجاهلها تظهر أنها لا تفهم.
استشهد بها عند بدء العمل. قبل بدء أي عمل، يجب أن يكون لكل عنصر في قائمة التحقق إجابة مؤكدة. العناصر المفتوحة عند بدء العمل تصبح مشكلات بحلول الأسبوع الرابع.
استخدمها للتحليل بعد التنفيذ. عندما يحدث شيء خاطئ، تتبع أي عنصر من قائمة التحقق فشل. تحديث القائمة للمرات القادمة.
ماذا لا تغطي هذه القائمة
بعض الأشياء التي لا تتضمنها القائمة عمدًا لأنها محددة جدًا للمشروع:
- متطلبات الميزات المخصصة المحددة (المكونة، مشاهد AR، بحث مخصص)، تحتاج إلى مستندات نطاق خاصة بها
- تنسيق حملة التسويق، فريق التسويق الخاص بك يمتلك هذا
- خطة الاتصال مع العملاء حول الانتقال، عادةً ما تكون غير ضرورية إذا كان الانتقال سلسًا
- خارطة طريق Hyvä طويلة الأجل (متى تضيف Checkout، متى تضيف Admin)، تحدث عن المرحلة الثانية بعد إطلاق المرحلة الأولى
إذا كان نطاقك يتضمن أيًا من تلك، قم بإعداد مستندات نطاق مفصلة منفصلة لها بالإضافة إلى هذه القائمة الأساسية.
لماذا 47؟
ليس رقمًا سحريًا. نمت القائمة على مر السنين حيث تعلمنا ما هي العناصر التي تعود إليها المفاجآت أثناء المشروع. حاليًا تتكون من 47 عنصرًا؛ من المحتمل أن تنمو إلى 52 في العامين المقبلين مع ظهور حالات جديدة.
النقطة ليست الرقم؛ بل وجود قائمة شاملة تقوم بمراجعتها مرة واحدة بدلاً من اكتشاف العناصر في الأسبوع الخامس من البناء.
الخطوات التالية
- راجع صفحة خدمة ترحيل Hyvä للعملية الكاملة
- اقرأ كيفية ترحيل Magento Luma إلى Hyvä في 8 أسابيع لتفصيل أسبوعي
- اقرأ تكلفة ترحيل Hyvä في 2026 لإطار التكلفة
- احجز مكالمة لتحديد النطاق، سنقوم بمراجعة هذه القائمة معًا