ย้ายข้อมูลจาก Excel เข้า Web App อย่างไร? วาง Data Migration ให้พร้อมก่อน Cutover

ระบบใหม่พัฒนาเสร็จ ไม่ได้แปลว่าข้อมูลเก่าพร้อมย้ายครับ จุดที่ทำให้ Data Migration เสี่ยงมักไม่ใช่ปุ่ม Import แต่คือทีมยังตอบไม่ได้ว่าไฟล์ไหนเป็น Source of Truth, คอลัมน์เดิมหมายถึงอะไร, รายการซ้ำควรรวมอย่างไร, ข้อมูลเก่าแค่ไหนที่ต้องย้าย และหลัง Import แล้วจะพิสูจน์อย่างไรว่าข้อมูลในระบบใหม่ครบและใช้งานต่อได้จริง

ถ้ากำลังเปลี่ยนจาก Excel, CSV, SaaS เดิม หรือระบบหลังบ้านเก่าไปเป็น Web App ผมจะแยกงาน Migration ออกจากงานพัฒนาฟังก์ชันให้ชัดก่อน เพราะสองงานนี้ใช้คำถามคนละชุด ระบบใหม่อาจมี Workflow ถูกต้องแล้ว แต่ถ้าเอาข้อมูลที่ซ้ำ ความหมายไม่ตรง หรือขาดความสัมพันธ์เข้าไป ระบบใหม่ก็เพียงรับปัญหาเก่าเข้ามาอยู่ในฐานข้อมูลใหม่เท่านั้น

บทความนี้จึงเริ่มจาก Current Data Flow → Failure/Risk → Migration Options → Requirement Pack → Trial Import/Reconcile → Cutover → Handoff เพื่อให้เจ้าของงาน ทีมข้อมูล และทีมพัฒนารู้ว่าใครต้องตัดสินใจอะไร และต้องมีหลักฐานอะไร ก่อนเปลี่ยน Source of Truth จริง

ก่อนถามว่า “Import ด้วยอะไร” ให้ถามก่อนว่าข้อมูลวันนี้เดินอย่างไร

ลองวาดงานหนึ่งเส้นจากของจริง เช่น Lead เข้ามาจาก LINE → Sales คัดลง Excel A → Admin เติมข้อมูลใน Excel B → เอกสารถูกเก็บใน Shared Drive → สถานะบางส่วนอยู่ในระบบเดิม → ผู้จัดการดูรายงานจากอีกไฟล์หนึ่ง หากลูกค้าคนเดียวกันมีชื่อสะกดต่างกันสามแบบ หรือ Order ID ถูกสร้างคนละระบบ การเริ่มเขียน Script ย้ายข้อมูลทันทีจะทำให้ทีมต้องตัดสินใจเรื่องสำคัญกลางการ Import ซึ่งเป็นจังหวะที่ผิดพลาดง่ายที่สุด

Requirement Discovery ของ Web App ควรตอบเรื่อง User, Workflow, Data, Rule และ Exception ก่อนอยู่แล้ว หาก Source of Truth ยังไม่ชัด ควรกลับไปล็อกความหมายของข้อมูลก่อน อ่านต่อได้ที่ การเตรียม Requirement Web App จากงานจริงก่อน Feature List

Current Data Flow อย่างน้อยควรเห็น 5 เรื่อง

• Source: ข้อมูลเริ่มจากไฟล์ ระบบ แบบฟอร์ม หรือคนใด
• Owner: ใครมีสิทธิ์ยืนยันว่าค่านี้ถูกต้อง
• Transformation: ระหว่างทางมีสูตร การคัดลอก การแก้ชื่อ หรือการคำนวณอะไร
• Relationship: Customer, Order, Project, Payment, Attachment เชื่อมกันด้วยรหัสอะไร
• Destination: หลัง Cutover ข้อมูลชุดไหนต้องอยู่ใน Web App และอะไรควรคงเป็น Archive

Failure Point ที่ควรปิดก่อนเริ่ม Data Migration

1. มีหลาย Source แต่ไม่มี Source of Truth

ถ้ารายชื่อลูกค้าใน Excel, CRM เดิม และระบบบัญชีไม่ตรงกัน การถามว่า “จะเอาไฟล์ไหนเข้า” ยังเร็วเกินไป ต้องระบุว่า Field ใดให้ระบบไหนเป็นผู้ยืนยัน เช่น ชื่อบริษัทอาจยึด CRM แต่ยอดค้างชำระยึดระบบบัญชี และต้องมี Owner ที่รับผิดชอบการตัดสินใจนั้น

2. ชื่อ Field เหมือนกัน แต่ความหมายทางธุรกิจไม่เหมือนกัน

คอลัมน์ Date อาจหมายถึงวันที่เปิด Lead, วันที่ลูกค้าสั่ง หรือวันที่ปิดงาน ส่วน Status อาจมีค่า “Done” ที่แต่ละทีมใช้คนละความหมาย การ Mapping ที่ดีจึงไม่ใช่แค่เปลี่ยนชื่อคอลัมน์ แต่ต้องล็อก Business Meaning, รูปแบบข้อมูล, Rule และค่าที่ต้องแปลงด้วย

3. ไม่มี Identity Rule สำหรับข้อมูลซ้ำ

ชื่อบริษัทเหมือนกันไม่ได้แปลว่าเป็น Record เดียว และชื่อไม่เหมือนกันก็ไม่ได้แปลว่าเป็นคนละราย ก่อน Dedupe ต้องกำหนด Matching Key เช่น Customer ID เดิม, Tax ID, Email หรือกติกาผสมตามข้อมูลจริง รวมถึงกรณีที่ Key หายหรือมีหลายค่า ห้ามให้ Script เดาแทน Owner โดยไม่มีหลักฐาน

4. คำว่า “ย้ายทั้งหมด” ยังไม่ผ่านการตัดสินใจ

ข้อมูลเก่าหลายปีอาจมีค่าต่อการอ้างอิง แต่ไม่จำเป็นต้องอยู่ในฐานข้อมูลใช้งานประจำทั้งหมด การย้ายทุกอย่างเพิ่ม Mapping, Validation, Storage และเวลาตรวจรับ บางกรณีเหมาะกับการย้ายเฉพาะ Master Data + งานที่ยัง Active แล้วเก็บประวัติที่เหลือเป็น Read-only Archive พร้อมวิธีค้นย้อนหลัง

5. ความสัมพันธ์ ไฟล์แนบ และสิทธิ์ถูกลืม

Migration ที่ดูเหมือน “Record ครบ” อาจยังใช้ไม่ได้ ถ้า Invoice หา Customer ไม่เจอ, Attachment หลุดจาก Project หรือข้อมูลลับถูกย้ายมาแต่ Permission ใหม่ยังไม่พร้อม จึงต้องตรวจทั้ง Record และ Relationship ไม่ใช่นับจำนวนแถวอย่างเดียว

6. ไม่มี Acceptance Rule ว่าอะไรคือ “ย้ายผ่าน”

คำว่า “Import สำเร็จ” เป็นเพียงสถานะทางเทคนิค ธุรกิจยังต้องกำหนด Reconciliation ว่าจะเทียบอะไร เช่น จำนวน Master Record, จำนวน Active Transaction, ยอดรวมตาม Control Total, จำนวน Attachment, รายการ Reject และ Sample ที่ Business Owner เปิดตรวจด้วยตา

เลือก Migration Option ให้เหมาะกับงาน ไม่ใช่ใช้สูตรเดียวทุกระบบ

ทางเลือก	เหมาะเมื่อ	Trade-off ที่ต้องยอมรับ
Migrate All	ประวัติทั้งหมดต้องค้น/ประมวลผลในระบบใหม่ และคุณภาพข้อมูลพิสูจน์ได้	Mapping, Cleaning และ Reconciliation มากที่สุด
Active + Master Data	ต้องใช้ลูกค้า/สินค้า/ผู้ใช้ทั้งหมด แต่ Transaction เก่าย้ายเฉพาะรายการที่ยังทำงานต่อ	ต้องกำหนดเส้นแบ่ง Active/Closed ให้ชัด
Archive Old Data	ข้อมูลเก่ามีไว้ค้นอ้างอิง ไม่ต้องแก้ต่อหรือใช้ใน Workflow ใหม่	ต้องมีวิธีเข้าถึง Archive และ Retention/Permission ที่เหมาะสม
Phased Migration	ข้อมูลหลายโมดูลหรือหลายหน่วยงาน และ Cutover ครั้งเดียวเสี่ยงเกินไป	ต้องบริหารช่วงที่สองระบบอยู่ร่วมกันและกำหนด Source of Truth ราย Phase

ไม่มีตัวเลือกไหน “ดีที่สุด” โดยไม่ดูบริบท คำถามหลักคือข้อมูลชุดนี้ต้องสนับสนุน Workflow หลังเปิดระบบอย่างไร ถ้าไม่ได้ใช้ใน Process, Report, Compliance หรือการอ้างอิงที่จำเป็น การย้ายเพราะกลัวว่าข้อมูลจะหายอาจสร้างภาระมากกว่าคุณค่า

Data Migration Readiness Pack 7 ชุดที่ผมอยากเห็นก่อน Trial Import

1. Source Register

รายการ Source ทั้งหมดพร้อม Location, Owner, Last Updated, Data Type, ความลับ/สิทธิ์ และคำตอบว่า Source ไหนเป็น Authoritative สำหรับ Field สำคัญ ถ้ามีไฟล์ชื่อ “final”, “final2”, “ล่าสุดจริง” หลายไฟล์ ให้แก้ Ownership ก่อนทำ Mapping

2. Target Object Map

ระบุว่า Sheet/Entity เดิมจะไปอยู่ Object ใดของระบบใหม่ เช่น Customer → Customer, งานขาย → Opportunity, ใบงาน → Job, ไฟล์แนบ → Attachment และบอกความสัมพันธ์ Parent/Child ที่ระบบใหม่ต้องรักษา

3. Field & Value Mapping

ต่อหนึ่ง Field ควรเห็น Source Field, Target Field, Business Meaning, Data Type, Required/Optional, Transformation Rule, Default Value, Allowed Values และ Owner ของกติกา เช่นค่าเดิม “P”, “Pending”, “รอ” อาจต้องรวมเป็นสถานะเดียว แต่การรวมต้องผ่านเจ้าของ Process ไม่ใช่ให้ Developer เลือกเอง

4. Data Quality Rules

กำหนดวิธีจัด Missing, Invalid, Duplicate, Orphan Relationship และค่าที่อยู่นอกขอบเขต พร้อมสถานะ Fix / Reject / Accept with Note วิธีนี้ทำให้ Exception ไม่ถูกซ่อนใน Script และย้อนดูได้ว่า Record ใดถูกเปลี่ยนเพราะกติกาอะไร

5. Migration Scope & Exclusion Log

เขียนขอบเขตเป็นคำตัดสิน เช่น “ย้าย Customer ทุก Record ที่ยังใช้งาน”, “ย้าย Order ตั้งแต่วันที่ X เฉพาะสถานะ Open/In Progress”, “ไฟล์แนบก่อนช่วงที่กำหนดเก็บใน Archive” และเก็บเหตุผลของสิ่งที่ไม่ย้ายเพื่อให้ทีมตอบคำถามย้อนหลังได้

6. Acceptance & Reconciliation Plan

กำหนด Control Total และ Business Checks ล่วงหน้า อย่ารอ Import เสร็จแล้วค่อยคิดว่าจะตรวจอะไร Microsoft Learn แนะนำให้วางแผน Testing/Validation ของ Migration และตรวจความถูกต้องหลังย้าย ส่วนสิ่งที่ Social Plus System ควรทำในบริบทธุรกิจคือแปลงหลักนี้เป็นหลักฐานที่ Owner อ่านได้ ไม่ใช่รายงาน Log ทางเทคนิคอย่างเดียว

7. Cutover & Rollback Plan

กำหนด Freeze Time, Final Export/Delta, Backup, คนสั่ง Go/No-Go, ขั้นตอนตรวจหลัง Import, ระยะที่ระบบเดิมเป็น Read-only และเงื่อนไข Rollback/Forward Fix แนวทางของ AWS และ Microsoft ต่างให้ความสำคัญกับการวาง Cutover ล่วงหน้าและการซ้อม/ตรวจ Runbook ก่อนเปลี่ยนระบบจริง

Trial Migration ต้องพิสูจน์ “ทำซ้ำได้” ไม่ใช่แค่ครั้งหนึ่งผ่าน

ผมไม่แนะนำให้ Trial Import เป็น Demo ที่ทีมเลือกข้อมูลสวย ๆ 20 แถวมาโชว์แล้วจบ Trial ที่มีประโยชน์ควรใช้ชุดข้อมูลที่สะท้อนปัญหาจริง มี Missing, Duplicate, ความสัมพันธ์หลายชั้น, ค่าเก่า และเคสที่ควรถูก Reject แล้วรันด้วยขั้นตอนเดียวกับที่จะใช้ใน Cutover มากที่สุดเท่าที่ทำได้

ลำดับที่ใช้งานได้คือ Inventory → Scope → Map → Clean → Trial Import → Reconcile → Fix → Repeat → Cutover ถ้า Trial รอบแรกพบว่า Customer 1 รายแตกเป็น 3 Records การแก้ที่ดีไม่ใช่รวมมือในระบบปลายทางแล้วเดินต่อ แต่ควรย้อนกลับไปแก้ Identity Rule หรือ Mapping แล้วรันใหม่ เพื่อให้ Runbook สุดท้ายสามารถทำซ้ำได้

Reconciliation Sheet ควรตอบว่า “เราพิสูจน์อะไรแล้ว”

จุดตรวจ	Evidence	Owner	ถ้าไม่ผ่าน
Master Records	Source count / Target count / Reject list	Data Owner	หยุดและวิเคราะห์ Missing/Duplicate
Active Transactions	Control total ตามสถานะ/ช่วงที่ตกลง	Process Owner	เทียบ Scope + Mapping + Filter
Relationships	Orphan report + sample check	System/Data Owner	แก้ Key/Load sequence
Attachments	Expected vs migrated + failed file log	Document Owner	Retry/Exclude พร้อมเหตุผล
Business Meaning	ตัวอย่าง Record ที่ Owner เปิดตรวจ	Business Owner	แก้ Transformation Rule

จำนวนรายการที่ต้อง Sampling ไม่มีเลขตายตัวที่ใช้ได้ทุกระบบ เพราะความเสี่ยงไม่เท่ากัน จุดสำคัญคือ Acceptance Criteria ต้องสัมพันธ์กับผลกระทบของข้อมูล และต้องตกลงก่อน Cutover ไม่ใช่สร้างเปอร์เซ็นต์ผ่านขึ้นมาเองหลังเห็นผล

Cutover Day: ใครทำอะไร เมื่อไร และอะไรทำให้หยุด

Cutover ที่ควบคุมได้ควรมี Timeline และ Owner ชัด ตัวอย่าง Flow คือ:

1. Freeze / Change Control: ระบุเวลาใดที่ผู้ใช้หยุดแก้ Source เดิม หรือเริ่มเก็บ Delta ด้วยวิธีที่กำหนด
2. Final Backup: เก็บสำเนา Source ก่อนย้าย พร้อมตรวจว่า Restore/Access ได้ตามความเสี่ยง
3. Final Extract: Export ข้อมูลตาม Scope และบันทึก Timestamp/Version
4. Transform & Load: ใช้ Mapping/Rule ที่ผ่าน Trial ไม่แก้สดโดยไม่มี Change Record
5. Reconcile: ตรวจ Control Total, Relationship, Reject และ Business Sample
6. Go / Conditional Go / No-Go: Business Owner + System Owner ตัดสินจาก Evidence ที่ตกลง ไม่ใช่จากความรู้สึกว่า Deadline ถึงแล้ว
7. Production Health Check: Login, Search, Create/Update, Workflow หลัก, Report/Integration ที่อาศัยข้อมูล Migration

เมื่อ Migration ผ่านแล้ว ขั้นถัดไปควรต่อกับ Deployment Readiness ก่อน Go-Live เพราะ Cutover เป็นเพียงหนึ่งส่วนของ Production Readiness ยังมี Backup/Restore, Permission, Integration, Monitoring, Rollback และ Support ที่ต้องพร้อมตามความเสี่ยงของระบบ

Risk Matrix: ปัญหา Migration ต้องมี Owner ไม่ใช่มีแต่ Developer

Risk	Owner หลัก	Evidence ก่อน Go
Source ไม่ตรงกัน	Business/Data Owner	Authoritative source decision
Duplicate/Identity ไม่ชัด	Data + Process Owner	Matching/Dedupe rule + exception log
Field meaning เปลี่ยน	Process Owner	Approved mapping + value transform
Record/Relationship หาย	Migration/System Owner	Reconciliation + orphan report
Cutover ใช้เวลาหรือผิดแผน	Release Owner	Runbook + freeze/rollback trigger
ผู้ใช้แก้ข้อมูลผิด Source หลังเปิด	Business/System Owner	Source-of-truth communication + access change

ตารางนี้ไม่ได้หมายความว่าบริษัทต้องมีหกตำแหน่งแยกกัน ทีมเล็กคนเดียวอาจถือหลายบทบาทได้ แต่ต้องรู้ว่าตอนนี้กำลังตัดสินใจในฐานะใคร เพราะ Developer ไม่ควรตัดสินเองว่าลูกค้าสองรายคือคนเดียวกัน และ Business Owner ก็ไม่ควรแก้ Data Type/Load Sequence โดยไม่มีทีมระบบประเมินผลกระทบ

หลัง Cutover งานยังไม่จบ: ต้องส่งต่อ Data Ownership ให้การทำงานประจำ

เมื่อ Web App กลายเป็น Source of Truth แล้ว ควรกำหนดทันทีว่าระบบเดิมเป็น Read-only หรือ Archive เมื่อไร ใครมีสิทธิ์แก้ Master Data, ใครดู Migration Reject ที่ยังค้าง, ข้อมูลเก่าจะเก็บนานเท่าไร และหากพบข้อมูลผิดหลังเปิดจริงจะ Correction ในระบบใหม่อย่างไรโดยไม่กลับไปแก้ Source เดิมแล้ว Import ทับซ้ำ

ถ้ากำลังอยู่ก่อนหน้าขั้น Migration และยังไม่แน่ใจว่าควรเปลี่ยนจาก Spreadsheet เป็นระบบใหม่หรือไม่ ให้เริ่มจาก Excel ควรเปลี่ยนเป็น Web App เมื่อไร ก่อน เพราะบางปัญหาแก้ได้ด้วยการจัด Source/Workflow โดยยังไม่ต้องสร้างระบบ แต่ถ้าตัดสินใจทำ Web App แล้ว Data Migration ควรถูกถือเป็น Workstream ของตัวเองตั้งแต่ Scope ไม่ใช่ของแถมช่วงท้ายโครงการ

Next Decision: ก่อนลงทุนทำ Migration Script ให้ล็อก 5 คำตอบนี้

1. ข้อมูลชุดไหนอยู่ใน Scope และชุดไหนเป็น Archive?
2. Field สำคัญแต่ละตัว ใครเป็น Owner และ Source ไหนเป็น Source of Truth?
3. Identity, Duplicate, Missing และ Transformation ใช้กติกาอะไร?
4. Trial Migration จะตรวจผ่านด้วย Evidence อะไร?
5. Cutover ใครสั่ง Go/No-Go และเมื่อผิดจะหยุด/ย้อน/แก้อย่างไร?

ถ้าห้าคำตอบนี้ยังไม่ชัด ผมจะยังไม่รีบล็อกเครื่องมือ Migration เพราะ Tool ไม่สามารถตัดสิน Business Meaning แทนทีมได้ แต่ถ้าล็อกได้แล้ว ทีมพัฒนาจะตี Scope, เลือกวิธี Import, ออกแบบ Validation และวาง Cutover ได้ตรงกว่าเดิมมาก

สำหรับธุรกิจที่กำลังออกแบบระบบหลังบ้านจาก Excel หรือ Workflow เดิม สามารถดูขอบเขตของ Web App และระบบหลังบ้านสำหรับธุรกิจ เพื่อใช้เป็นขั้นถัดไปหลัง Process, Requirement และ Data Ownership ชัดแล้ว จุดตัดสินใจสำคัญไม่ใช่ว่าจะใช้เทคโนโลยีอะไรเร็วที่สุด แต่คือทำให้ Process, คน, ข้อมูล และระบบ อ้างอิงความจริงชุดเดียวกันได้หลังเปิดใช้ครับ

แหล่งอ้างอิงที่ใช้วางกรอบ Migration

• Microsoft Learn — Data migration overview
• Microsoft Learn — Data migration approaches
• Microsoft Learn — Import data
• AWS Prescriptive Guidance — Cutover stage