COUNT
كم عميلًا، طلبًا، منتجًا، balance record أو future booking تم نقله؟
الـlegacy يحمل قيمة تجارية يجب الحفاظ عليها، لكنه يحمل أيضًا taxonomies وبيانات غير متسقة. لذلك migration engineering يبدأ مبكرًا، مع rehearsals وreconciliation قبل cutover النهائي.
الـfinal cutover يحدث قرب النشر، لكن mapping وscripts وreconciliation يجب أن تكون قد مرت على بيانات حقيقية في rehearsals قبل ذلك.
لا يكفي أن تنتهي الـscript بدون error. يجب أن نثبت العدد والقيمة والعلاقات، ثم نفحص سجلات حقيقية كما تظهر للمستخدم والـAdmin.
كم عميلًا، طلبًا، منتجًا، balance record أو future booking تم نقله؟
هل totals المالية، wallet opening balance، stock totals وغيرها تتطابق؟
هل كل order مرتبط بالعميل والعنوان والمجموعة والمنتج الصحيح؟
هل تظهر سجلات حقيقية بشكل صحيح في App/Web/Admin بعد النقل؟
لو نقلنا تاريخ الطلبات ولم ننقل الالتزامات المستقبلية إلى capacity model الجديد، يمكن أن نفتح سعة وهمية ونخلق double-booking لحظة الإطلاق.
Confirmed legacy bookings = 5
Legacy slot commitments = activeMario capacity = 10
Migrated committed = 5
Remaining = 5No future legacy delivery commitment exists outside the new capacity system. نفس القاعدة تنطبق على Delivery Slots.
كل domain له mapping واضح، validation وreconciliation مناسب له؛ وبعض البيانات مثل reviews/wishlist تُنقل فقط إذا كانت موثوقة.
لا نفترض أن كل legacy hash بنفس algorithm.
الـlegacy لا يغلق بمجرد أن تبدو الواجهة الجديدة جيدة.