นำเข้าข้อมูลได้โดยไม่มีข้อความผิดพลาด ยังไม่เท่ากับย้ายข้อมูลสำเร็จ รายการอาจมาครบจำนวนแต่ผูกกับลูกค้าผิดคน วันที่เปลี่ยนความหมาย หรือไฟล์แนบเปิดไม่ได้เมื่อผู้ใช้งานจริงเข้าระบบ
การตรวจรับควรครอบคลุมทั้งข้อมูลและงานที่ต้องทำต่อ กำหนดไว้ก่อนว่าต้องเห็นหลักฐานอะไรจึงจะเปิดใช้ และใครเป็นคนตัดสินเมื่อพบข้อแตกต่างที่ยังอธิบายไม่ได้
ก่อนย้าย: ระบุสิ่งที่จะเอาไปและสิ่งที่เก็บอ้างอิง
ทำบัญชีชุดข้อมูล เช่น ลูกค้า สินค้า รายการขาย งานค้าง ประวัติแก้ไข และไฟล์แนบ ระบุเจ้าของ แหล่งต้นฉบับ ปริมาณโดยประมาณ ความสัมพันธ์ และสิทธิ์ที่ต้องรักษา ไม่ควรเริ่มจากส่งออกทุกไฟล์แล้วค่อยดูว่าจะใช้ส่วนไหน
ตกลงว่าข้อมูลเก่าประเภทใดต้องอยู่ในระบบใหม่ และประเภทใดเก็บอ่านย้อนหลังจากแหล่งเดิมได้ การย้ายงานค้างที่ต้องทำต่ออาจมีเงื่อนไขต่างจากประวัติที่ใช้ค้นอ้างอิงเท่านั้น
สำรองต้นฉบับก่อนแปลง พร้อมระบุช่วงข้อมูลและเวลาที่บันทึก เก็บไฟล์ที่ใช้ย้ายกับกติกาแปลงเป็นรุ่นที่ตรวจย้อนกลับได้ อย่าแก้ข้อมูลต้นทางจนไม่เหลือหลักฐานของสภาพก่อนย้าย
ตกลงวิธีแปลงช่องข้อมูล
ระบุว่าช่องเดิมจะไปอยู่ที่ใด ค่าที่ไม่รู้จักจะทำอย่างไร และช่องไหนจำเป็นต้องมี ทดสอบรหัสมีเลขศูนย์นำหน้า ภาษาไทย บรรทัดใหม่ ทศนิยม ช่องว่าง และค่าว่างที่ต่างจากเลขศูนย์
วันที่ต้องตรวจทั้งรูปแบบวันเดือนปี ปีพุทธศักราชกับคริสต์ศักราช และเขตเวลา อย่าใช้การแปลงแบบเดาวันจากข้อความโดยไม่มีตัวอย่างยืนยัน เพราะวันที่ที่ดูถูกต้องอาจถูกสลับเดือนหรือเลื่อนไปอีกวันแล้ว
รอบทดลอง: เปรียบเทียบจากจุดเวลาเดียวกัน
ทดลองกับข้อมูลที่เป็นตัวแทนของงานจริง รวมรายการเก่า งานค้าง กรณีผิดปกติ และไฟล์แนบ เลือกช่วงต้นทางกับปลายทางที่เทียบกันได้ หากต้นทางยังเปลี่ยนอยู่ ต้องรู้ว่าการเปลี่ยนแปลงหลังตัดรอบจะตามไปอย่างไร
เริ่มจากจำนวนรายการแยกประเภทและผลรวมที่เหมาะกับข้อมูล แล้วตามด้วยการตรวจระดับรายการ จำนวนรวมเท่ากันอาจเกิดจากขาดบางรายการและมีบางรายการซ้ำมาชดเชย จึงต้องมีรหัสอ้างอิงสำหรับเทียบรายตัว
เอกสารการตรวจสอบข้อมูลของ AWS DMS อธิบายการเทียบข้อมูลต้นทางกับปลายทางและรายงานความต่าง โดยมีเงื่อนไขและภาระการทำงานของเครื่องมือ การตรวจลักษณะนี้ช่วยพิสูจน์ระดับข้อมูล แต่ยังต้องตรวจไฟล์ สิทธิ์ และงานใช้งานของธุรกิจเพิ่ม
ตรวจความสัมพันธ์และประวัติ
เปิดคำสั่งซื้อแล้วต้องพบลูกค้า รายการสินค้า และเอกสารที่เกี่ยวข้องถูกชุด งานค้างต้องยังมีสถานะและเจ้าของที่ทำต่อได้ ไม่ใช่เหลือเพียงข้อความประวัติที่ระบบใหม่ใช้ดำเนินการไม่ได้
ตรวจรายการที่ยกเลิก แก้ไข และคืนบางส่วนด้วย หากย้ายเฉพาะค่าล่าสุด ต้องยืนยันว่าประวัติที่จำเป็นยังหาได้จากที่ใด และไม่ทำให้ผู้อ่านเข้าใจว่ารายการไม่เคยถูกเปลี่ยน
ตรวจรับ: ให้ผู้ใช้ลองทำงานต่อจริง
ให้ผู้ใช้แต่ละหน้าที่ทดสอบสิ่งที่ต้องทำ เช่น ค้นลูกค้า เปิดเอกสาร ทำงานค้างต่อ และออกรายงาน ใช้สิทธิ์ตามบทบาทจริง เพราะบัญชีผู้ดูแลที่เปิดได้ทุกอย่างอาจมองไม่เห็นปัญหาสิทธิ์ของทีม
สร้างรายการข้อแตกต่างพร้อมจำนวนที่ได้รับผล ตัวอย่าง สาเหตุ และผู้รับผิดชอบแก้ แยกสิ่งที่แปลงตามข้อตกลงออกจากข้อผิดพลาด ห้ามยอมรับส่วนต่างที่ยังไม่รู้สาเหตุเพียงเพราะยอดรวมใกล้เคียง
เกณฑ์ผ่านต้องชัดก่อนวันเปลี่ยนระบบ เช่น ไม่มีรายการอ้างอิงที่หลุดในขอบเขตที่ย้าย ไฟล์สำคัญเปิดได้ และกระบวนการที่จำเป็นทำต่อได้ ส่วนข้อยกเว้นที่ยอมรับต้องมีเจ้าของอนุมัติและทางจัดการที่บันทึกไว้
เก็บหลักฐานเทียบกับเกณฑ์แต่ละข้อ แทนการสรุปรวมว่า “ดูแล้วน่าจะครบ” เมื่อแก้กรณีที่ไม่ผ่าน ให้ตรวจซ้ำเฉพาะส่วนที่เกี่ยวข้องและยืนยันว่าการแก้ไม่ทำให้รายการที่เชื่อมกันเปลี่ยนผิดไปด้วย
วันเปลี่ยนระบบ: ควบคุมรายการที่เข้าระหว่างทาง
ระบุช่วงหยุดรับหรือวิธีเก็บการเปลี่ยนแปลงหลังตัดรอบ ใครตรวจชุดสุดท้าย และเมื่อไรจึงให้ทีมเริ่มเขียนข้อมูลในระบบใหม่ หลีกเลี่ยงการให้ทั้งสองระบบรับแก้ไขพร้อมกันโดยไม่มีวิธีกระทบยอด
แผนกลับคืนต้องคิดถึงข้อมูลใหม่ที่เกิดหลังเปิดใช้ด้วย การเปิดระบบเก่ากลับมาเฉย ๆ อาจทำให้รายการที่เพิ่งรับในระบบใหม่หาย ต้องกำหนดว่าจะส่งกลับ พักงาน หรือกระทบยอดอย่างไร รวมถึงใครตัดสินใจใช้แผนนั้น
หลังเปิดใช้ ให้ติดตามข้อผิดพลาดและยอดสำคัญในช่วงที่ตกลงกัน เก็บต้นฉบับและหลักฐานตรวจรับตามนโยบายของธุรกิจ ก่อนตัดสินใจเลิกใช้แหล่งเดิม
หากรหัสต้นทางยังไม่ตรงกัน ให้เริ่มจากจัดรหัสสินค้าก่อนเชื่อมข้อมูล และนำหลักจากการกู้คืนงานอัตโนมัติเมื่อเกิดข้อขัดข้อง มาช่วยวางทางรับมือเมื่อขั้นตอนย้ายไม่จบตามแผน
กำลังเปลี่ยนระบบ แต่ยังไม่มั่นใจว่าข้อมูลจะตามมาครบ?
Talvyn Labs ช่วยวางแผนย้ายข้อมูล ทดลองเทียบต้นทางกับปลายทาง และกำหนดเกณฑ์ตรวจรับก่อนเปิดใช้งานจริง
วางแผนย้ายข้อมูลกับ Talvyn Labs