نقل متجر إلى سلة يبدأ بإثبات ما يمكن نقله ومطابقته، لا بنسخ الصفحة الرئيسية. قبل الاتفاق على التنفيذ، اطلب جردًا للبيانات والروابط والتكاملات، وتجربة نقل صغيرة، وخطة واضحة للطلبات التي تصل أثناء الانتقال. نجاح الاستيراد رسالة تقنية؛ نجاح النقل يعني أن فريقك يستطيع البيع وخدمة الطلبات القديمة دون التباس.
يناسب هذا المسار من لديه متجر يعمل بالفعل ويريد الانتقال لأسباب تشغيلية محددة. اكتب تلك الأسباب أولًا: صعوبة إدارة المنتجات، تعقيد التشغيل، أو عدم ملاءمة المنصة الحالية. إذا لم تعرف المشكلة التي تريد حلها، قد تنقل الفوضى نفسها إلى واجهة جديدة. ينبغي أن يفصل عرض تطوير وإطلاق متاجر سلة بين تجهيز الوجهة وبين نقل البيانات والتحقق منها.
حدّد مصير كل نوع من البيانات
أنشئ قائمة لا تقتصر على المنتجات. أضف الخيارات والمخزون والصور والتصنيفات والعملاء والطلبات المفتوحة وسجل الطلبات والقسائم والروابط والاشتراكات. لكل نوع، اختر مصيرًا: نقل قابل للاختبار، إعادة إعداد، أرشيف مرجعي، أو استبعاد معتمد. لا تجعل كلمة «كامل» بديلًا عن هذه القرارات.
توثّق سلة مسارات مختلفة لاستيراد المنتجات بحسب المنصة المصدر؛ وجود مسار للمنتجات لا يثبت نقل كل الكائنات التاريخية. دليل سلة للاستيراد من منصات أخرى.
| العنصر | قرار يجب حسمه | دليل القبول |
|---|---|---|
| المنتجات ومتغيراتها | العلاقة بين المنتج ورمز كل خيار | تطابق الرمز والوصف والسعر |
| الطلبات المفتوحة | أين يستمر تجهيزها وإرجاعها؟ | مسؤول ومسار وصول معروفان |
| العملاء | البيانات اللازمة والغرض من نقلها | صلاحية الوصول ومراجعة العينة |
| الصور | ملفات مملوكة أم روابط خارجية؟ | استمرار ظهور الأصل الصحيح |
| الروابط القديمة | إبقاء أو تحويل أو إزالة مبررة | خريطة وجهات مختبرة |
الاحتفاظ بسجل قديم لا يعني عرضه كله في لوحة جديدة. قد يكون الأرشيف المقيّد أكثر وضوحًا من استيراد غير مكتمل يوحي بأن التاريخ شامل. يحدد المسؤول المختص مدة الاحتفاظ والصلاحيات وفق التزامات النشاط؛ لا يقرر منفّذ المتجر ذلك من تلقاء نفسه.
ابنِ خريطة بين المصدر والوجهة
لكل حقل، سجّل اسمه القديم والجديد، وصيغته، والتحويل المطلوب، والمسؤول عن اعتماد قيمته. فرّق بين رمز المنتج ومعرّفه داخل المنصة؛ ليس من الضروري أن يبقيا متطابقين بعد النقل. اعتمد مفتاحًا يمكن به تتبّع السجل بين الطرفين دون الاعتماد على الاسم القابل للتعديل.
راجع خصوصًا القيم الفارغة، والوحدات، وخيارات اللون والمقاس، والأسعار قبل وبعد الخصم. هل الصفر يعني نفادًا أم أن الكمية غير معروفة؟ وهل صورة المجموعة تمثل جميع المتغيرات؟ أسئلة كهذه تمنع تحميلًا صحيح الشكل وخاطئ المعنى. لا يصحح النظام معلومة تجارية لا يعرفها فريقك.
إذا احتاج النقل إلى تكامل، افصل إثبات إمكانية الوصول والحقول المدعومة عن بناء الربط. نطاق تطوير وربط واجهات برمجة التطبيقات يجب أن يسمّي النظامين، واتجاه النقل، وقاعدة التعامل مع التكرار والأخطاء، ومن يوافق على البيانات المنقولة. لا تفترض أن وجود API يعني إتاحة كل حقل للكتابة.
مثال افتراضي لمطابقة كتالوج من 120 منتجًا
هذا مثال تعليمي، وليس نتيجة مشروع نفّذته LAB. لدى تاجر 120 منتجًا أساسيًا؛ يقرر إطلاق 112 منها وأرشفة ثمانية متوقفة. تتضمن المنتجات المختارة 36 رمزًا لمتغيرات قابلة للبيع. يثبت الفريق أولًا معنى العد: هل التقرير يعد المنتجات الرئيسية أم المتغيرات؟ لذلك لا يقارن رقم 112 بمجموع يجمع النوعين.
تضم تجربة النقل خمسة منتجات: بسيط، ومتعدد المقاسات، وناقص المخزون، وله خصم مؤقت، وله صور متعددة. تكشف التجربة أن اسم لون واحد مختلف بين الملف والمستودع. يصحح التاجر القاموس قبل نقل بقية السجلات، ثم يراجع الفريق المنتجات المختارة والمتغيرات كلًا على حدة. كل سجل مستبعد له سبب، وكل خطأ له مالك؛ لا تُخفى الفروق داخل عبارة «نسبة نجاح عالية».
تُراجع أيضًا عينة من الطلبات القديمة في موضع حفظها، للتأكد من قدرة الموظف على معرفة ما بيع والرد على استفسار العميل. هذا اختبار لاستمرارية العمل، لا ادعاء بأن جميع الطلبات استوردت إلى سلة.
خطّط للحظة التحويل وللرجوع
حدد وقت آخر استخراج، ومن يمنع التعديل المتزامن، وكيف تسجّل الطلبات والمخزون المتغير بعده. إذا وصل طلب بعد استخراج البيانات وقبل التحويل، يجب أن تعرف أي نظام يستقبله ومن يخصم مخزونه. خطة الانتقال التي تتجاهل هذه الفترة قد تنتج بيانات سليمة لكنها قديمة.
قبل تحويل النطاق، اعتمد شروط التوقف: اختلاف أسعار غير محلول، غياب وسيلة دفع أساسية، أو فقدان الوصول للطلبات المفتوحة. عيّن صاحب القرار وخيار الرجوع المتاح فعلًا. رجوع الواجهة لا يعكس تلقائيًا الطلبات التي نشأت في الوجهة الجديدة؛ تحتاج هذه الطلبات تسوية منفصلة.
أما الروابط، فخصص لها مسار تحسين الظهور في البحث مرتبطًا بخريطة الصفحات. توصي Google بتوجيه الروابط إلى وجهات ذات صلة، وتحذّر من تحويلها جماعيًا إلى صفحة رئيسية غير مناسبة. إرشادات نقل المواقع. لا يُعد هذا ضمانًا لبقاء ترتيب البحث.
ما الذي تستلمه قبل إغلاق المشروع؟
اطلب تقرير اختبار وضمان جودة البرمجيات يربط كل اختبار بسجله ونتيجته: مطابقة المنتجات والمتغيرات، فحص الصور، اختبار رحلة الطلب، مراجعة الروابط، وإثبات وصول الفريق للأرشيف. أضف سجل الفروق المقبولة، والمسؤول عن المتبقي، وتاريخ إعادة الاختبار. لا تعتمد تقريرًا يذكر النجاح دون توضيح ما اختُبر.
أسئلة شائعة
هل يمكن نقل كل شيء تلقائيًا؟
ليس وعدًا صالحًا قبل الفحص. تعتمد الإجابة على المصدر والوجهة والصلاحيات والخصائص المدعومة؛ اختبر عينة ممثلة ثم اعتمد جدولًا لما ينقل وما يبقى مرجعيًا.
هل تساوي أعداد المنتجات يكفي؟
لا. قد تتساوى الأعداد بينما تتكرر رموز أو تتبدل أسعار وصور. قارن الهوية والمعنى والعلاقات، إضافة إلى الأعداد.
متى أغلق المتجر القديم؟
بعد حسم مصير الطلبات المفتوحة والأرشيف والروابط والوصول التشغيلي. لا تجعل تشغيل المتجر الجديد وحده سببًا لحذف المصدر.
هل يجب تغيير تصميم المتجر أثناء النقل؟
ليس بالضرورة. فصل تغييرات البيانات والتشغيل عن تغييرات العرض يسهل اكتشاف مصدر الخطأ وتحديد ما يحتاج إعادة اختبار.
الخطوة التالية
جهّز تصديرًا مصرحًا به من المصدر وعينة منتجات صعبة وقائمة الطلبات المفتوحة. اطلب تجربة نقل محدودة ومطابقة موثقة قبل الالتزام بالنقل الشامل.
المصادر
رُوجعت في 26 أكتوبر 2026: استيراد المنتجات في سلة، ونقل المواقع لدى Google.