ย้ายจาก Pivotal Tracker, Jira และตัวติดตามงานอื่น

East Agile Tracker นำเข้าจากแหล่งที่มา สิบเอ็ด แหล่ง สิบแหล่งอ่านไฟล์ส่งออกที่เครื่องมืออื่นสร้างไว้อยู่แล้ว ส่วน GitHub เชื่อมต่อกับ repository โดยตรง ทุกแหล่งผ่านหน้าจอเดียวกันและตัวอย่างเดียวกัน ดังนั้นขั้นตอนด้านล่างจึงใช้ได้กับทุกแหล่ง ส่วนถัดจากนั้นจะบอกว่าแต่ละแหล่งนำอะไรมาด้วย

นำไฟล์ส่งออกเข้ามา

1. ส่งออกงานของคุณจากเครื่องมืออื่น — ส่วนของแหล่งที่มาของคุณด้านล่างจะบอกชื่อเมนู
2. เปิด Project Settings → Import / Export บนโปรเจกต์ที่คุณต้องการให้ story ไปอยู่ สร้างโปรเจกต์เปล่าขึ้นมาก่อนถ้าคุณยังไม่มี
3. เลือกแหล่งที่มา แล้วเลือกไฟล์ส่งออก
4. รัน ตัวอย่างแบบ dry-run มันจะแยกวิเคราะห์ไฟล์ทั้งไฟล์และรายงานว่าการนำเข้าจริงจะทำอะไร — story และป้ายกำกับกี่รายการ ข้ามไปกี่แถว และใครที่จับคู่กับสมาชิกไม่ได้ — โดยไม่เขียนอะไรเลย
5. นำเข้า

การนำเข้าไฟล์เดิมซ้ำนั้นปลอดภัย แถวที่ถูกนำเข้าไปแล้วจะถูกจับคู่ด้วย source id ของมันและถูกข้ามไป ดังนั้นการรันครั้งที่สองจะเป็นการเติมเข้าไปในโปรเจกต์แทนที่จะสร้างซ้ำ

การอัปโหลดจำกัดที่ 10 MiB และการนำเข้าครั้งเดียวจำกัดที่ 5,000 story การย้ายที่ใหญ่กว่านั้นจะแบ่งเป็นชุด ๆ และเพราะการนำเข้าซ้ำเป็น idempotent ชุดเหล่านั้นจึงทับซ้อนกันได้โดยไม่สร้างรายการซ้ำ

สิ่งที่ทุกแหล่งนำมาด้วย

• story สถานะ และป้ายกำกับ ทุกแถวหรือการ์ดจะกลายเป็น story โดย status ของมันจะไปอยู่ที่สถานะที่ใกล้ที่สุดบนวงจร unstarted → started → finished → delivered → accepted และป้ายกำกับของมันก็ตามมาด้วย status ที่ถูกยกเลิกหรือ won’t-fix จะมาถึงในสถานะ rejected และถูกเก็บถาวร งานที่ถูกละทิ้งจึงไม่อยู่บนบอร์ดและไม่นับรวมในความเร็ว
• เจ้าของ ช่องที่มีอีเมลตรงกับสมาชิกจะผูกสมาชิกคนนั้น ค่าอื่นใด — ชื่อที่ใช้แสดง ชื่อผู้ใช้ — จะผูกบุคคลภายนอกแบบแสดงผลเท่านั้น ดังนั้นข้อมูลว่าใครเป็นเจ้าของอะไรจึงยังคงอยู่แม้กับคนที่ไม่มีบัญชีที่นี่
• วันที่ วันที่สร้างและวันที่เสร็จถูกนำเข้า ทำให้รอบงานในอดีตและกราฟที่อ่านค่าเหล่านั้นมีข้อมูลแทนที่จะว่างเปล่า
• รอบงาน สำหรับทุกแหล่งที่ไฟล์ส่งออกมี sprint หรือ cycle

ผู้ขอ ความคิดเห็น epic และ task ขึ้นอยู่กับแหล่งที่มา ส่วนของแหล่งนั้นด้านล่างจะบอกว่ามีอะไรบ้าง

อะไรที่ไม่ตามมาด้วย

• ไฟล์แนบ ไม่มีตัวนำเข้าใดพาไฟล์มาด้วย story จะมาถึงโดยไม่มีไฟล์แนบ
• คนในฐานะบัญชีผู้ใช้ เจ้าของ ผู้ขอ หรือผู้แสดงความคิดเห็นที่ยังไม่ได้เป็นสมาชิกจะถูกผูกเป็นบุคคลภายนอกแบบแสดงผลเท่านั้น ไม่มีอะไรหายไปและไม่มีอะไรถูกให้เครดิตผิด แต่จะไม่มีการสร้างบัญชีและไม่มีการส่งคำเชิญ — เชิญพวกเขาตามปกติแล้วประวัติของพวกเขาก็ผูกอยู่แล้ว
• วันที่แก้ไขล่าสุด ไม่มีเวลาประทับ updated ติดเข้ามาด้วย
• รายละเอียดของ workflow status ที่กำหนดเองจะยุบลงไปอยู่ที่สถานะที่ใกล้ที่สุดในวงจรข้างบน ตัวอย่างแบบ dry-run คือที่สำหรับตรวจดูตัวอย่างก่อนนำเข้าโปรเจกต์ขนาดใหญ่

จาก Pivotal Tracker

แหล่งที่มา: Pivotal Tracker (CSV export) Pivotal Tracker ปิดตัวไปเมื่อ 30 เมษายน 2025 จึงไม่มีบริการที่ยังทำงานอยู่ให้ส่งออกข้อมูลได้อีก ตัวนำเข้านี้อ่านไฟล์ CSV ที่ส่งออกเก็บไว้ก่อนการปิดตัว บอร์ด สถานะของ story กับวงจรการตรวจรับเป็นไปตามแบบจำลองเดียวกัน ดังนั้นโปรเจกต์ที่นำเข้ามาจึงอ่านได้แบบเดียวกับที่เคยเป็น

Pivotal Tracker	กลายเป็น
Title, Description	ชื่อเรื่องและคำอธิบายของ story คอลัมน์ URL จะถูกเก็บไว้เป็นที่มาของ story และจะมีลิงก์ View original issue ถูกเพิ่มเข้าไปในคำอธิบายที่มีข้อความอยู่
Type	ประเภท story — feature, bug, chore และ release ล้วนมีสิ่งที่เทียบเท่าโดยตรง
Current State	สถานะของ story
Estimate	ค่าประมาณเป็นแต้มของ story
Labels	ป้ายกำกับ หนึ่งป้ายต่อหนึ่งค่า
Owned By	เจ้าของของ story Pivotal จะทำคอลัมน์นี้ซ้ำต่อเจ้าของหนึ่งคน และทุกคอลัมน์จะถูกอ่าน
Requested By	ผู้ขอของ story
Comment (หนึ่งคอลัมน์ต่อหนึ่งความคิดเห็น)	ความคิดเห็นของ story พร้อมผู้เขียนเดิมและเวลาประทับเดิม
Task / Task Status	task บน story โดย task ที่เสร็จแล้วจะมาถึงในสถานะเสร็จ
Blocker / Blocker Status	ตัวขัดขวาง โดยตัวที่แก้ไขแล้วจะมาถึงในสถานะแก้ไขแล้ว
แถว Type=epic	epic จริง ๆ ที่ถูกสร้างขึ้นใหม่และเชื่อมกับ story ที่อ้างถึงมัน พร้อมคำอธิบายของ epic
Iteration, Iteration Start	ตารางรอบงาน story จากรอบงานที่ยังไม่เริ่มจะอยู่ใน Backlog ต่อไป โดยจัดอันดับตาม sprint
Created at, Accepted at	วันที่สร้างและวันที่เสร็จของ story
Deadline	วันที่ที่วางแผนไว้ของ story ประเภท release

ไฟล์ส่งออกของ Pivotal ไม่มีคอลัมน์เวลาเริ่มงาน ค่าเวลารอบวงจร (cycle time) ของ story ที่นำเข้ามาจึงยังว่างอยู่ แถว epic ที่ไม่มี story ใดอ้างถึงจะไม่สร้างอะไรขึ้นมา เพราะ epic ถูกสร้างขึ้นใหม่ผ่าน story สมาชิกของมัน

จาก Jira

แหล่งที่มา: Jira (CSV export) ใน Jira ให้ค้นหา issue ที่คุณต้องการ แล้วใช้ Export → Export Excel CSV (all fields) ใช้การส่งออกแบบ all fields — การส่งออกแบบ current fields จะตัดคอลัมน์ sprint แต้ม story และความคิดเห็นออก

Jira	กลายเป็น
Summary	ชื่อเรื่องของ story แถวที่ summary ว่างจะไม่ถูกนำเข้า
Description	คำอธิบายของ story ที่แปลงจาก wiki markup ของ Jira เป็น markdown หัวเรื่อง ตัวหนา บล็อกโค้ด รายการ และลิงก์จะถูกแปลง ส่วนอื่น ๆ จะถูกเก็บไว้เป็นข้อความตามตัวอักษร
Issue Type	ประเภทของ story — Bug กลายเป็น bug, Story และ Feature กลายเป็น feature และ Task กลายเป็น chore
Status	สถานะของ story
Priority	ลำดับความสำคัญของ story จาก Highest ลงไปถึง Lowest
ฟิลด์กำหนดเองของแต้ม story	ค่าประมาณของ story คอลัมน์แรกที่หัวคอลัมน์กล่าวถึงแต้ม story จะถูกใช้ ดังนั้นทั้ง Custom field (Story Points) และ Custom field (Story point estimate) ใช้ได้ทั้งคู่
Labels	ป้ายกำกับ หนึ่งป้ายต่อหนึ่งค่า
Fix Version/s	ป้ายกำกับ Release: <version> หนึ่งป้ายต่อหนึ่งค่า
Sprint	ตารางรอบงาน Jira จะทำคอลัมน์นี้ซ้ำหนึ่งครั้งต่อ sprint ที่ issue ผ่านไป และอันสุดท้ายคือที่ที่มันไปจบลง ส่วน sprint ที่มีชื่อก็ยังคงอยู่ในรูปป้ายกำกับ Sprint: <name> ด้วย
Assignee	เจ้าของของ story ในรูปบุคคลภายนอกแบบแสดงผลเท่านั้น — CSV ของ Jira ไม่มีที่อยู่อีเมลให้จับคู่กับสมาชิก
Reporter	ผู้ขอของ story ตามกฎเดียวกัน
Comment (หนึ่งคอลัมน์ต่อหนึ่งความคิดเห็น)	ความคิดเห็นของ story แต่ละอันพร้อมผู้เขียนและเวลาประทับเดิมของมัน
issue ประเภท Sub-task	task บน story แม่ โดยงานย่อยที่เสร็จแล้วจะมาถึงในสถานะเสร็จ งานย่อยที่แม่ของมันไม่อยู่ในไฟล์จะกลายเป็น story ของตัวเอง
issue ประเภท Epic	ป้ายกำกับที่ตั้งชื่อตาม epic นั้น ติดไปกับ issue ลูกทุกอันที่อยู่ในนั้น
Issue key	ต่อท้ายคำอธิบายในรูปข้อความธรรมดา (Original issue: PROJ-12)
Created, Resolved	วันที่สร้างและวันที่เสร็จของ story

epic ของ Jira จะมาถึงเป็นป้ายกำกับบนลูกของมัน ไม่ใช่ระเบียน epic การจัดกลุ่มยังคงอยู่และค้นหาได้ แต่คำอธิบายของตัว epic เองไม่คงอยู่ Jira ส่งออกชื่อ sprint แต่ไม่ส่งออกวันที่ของมัน รอบงานจึงถูกเรียงตามชื่อ sprint

จาก Linear

แหล่งที่มา: Linear (CSV export) — ใน Linear ไปที่ Workspace settings → Import/Export → Export CSV

• Assignee กลายเป็นเจ้าของ และ Creator กลายเป็นผู้ขอ
• Project กลายเป็น epic ของ story
• sub-issue กลายเป็น task บน story แม่ของมัน
• cycle สร้างตารางรอบงาน story ใน cycle ที่ยังไม่เริ่มจะอยู่ใน Backlog ต่อไป โดยจัดอันดับตาม cycle
• คอลัมน์ Started ถูกอ่าน ดังนั้นเวลารอบวงจรจึงใช้ได้กับ story ที่นำเข้ามา
• CSV ของ Linear ไม่มีคอลัมน์ประเภท: story ที่มีป้ายกำกับ Bug จะมาถึงเป็น bug นอกนั้นเป็น feature
• ไฟล์ CSV ที่ส่งออกจาก Linear ไม่มีความคิดเห็น และ issue ที่ถูกเก็บถาวรจะถูกข้ามไป

จาก Asana

แหล่งที่มา: Asana (CSV export) — ใน Asana ไปที่ Project menu → Export/Print → CSV

• Assignee กลายเป็นเจ้าของ โดยจับคู่กับสมาชิกผ่าน Assignee Email เมื่อมีค่านี้
• tag กลายเป็นป้ายกำกับ
• subtask กลายเป็น task บน story แม่ของมัน
• task ที่มีวันที่ Completed At จะมาถึงในสถานะ accepted
• CSV ของ Asana ไม่มีคอลัมน์ผู้สร้างและไม่มีความคิดเห็น ดังนั้นสมาชิกที่ทำการนำเข้าจะเป็นผู้ขอ

จาก Trello

แหล่งที่มา: Trello (JSON export) — ใน Trello ไปที่ Menu → Print and export → Export as JSON

• การ์ดแต่ละใบกลายเป็น story และรายการที่การ์ดอยู่จะกำหนดสถานะของมัน (To Do, Doing, Done และชื่อในทำนองเดียวกัน)
• สมาชิกบนการ์ดกลายเป็นเจ้าของ
• ความคิดเห็นตามมาพร้อมผู้เขียนและเวลาประทับ
• รายการใน checklist กลายเป็น task
• ป้ายกำกับคงชื่อและสีไว้ ป้ายกำกับที่มีสีแต่ไม่มีชื่อจะมาถึงเป็น Trello-<colour>
• การ์ดที่ถูกเก็บถาวรจะมาถึงในสถานะเก็บถาวร
• การ์ดที่มีป้ายกำกับ Bug จะมาถึงเป็น bug Trello ไม่มี epic และไม่มีค่าประมาณ จึงไม่มีการสร้างทั้งสองอย่าง

จาก Shortcut

แหล่งที่มา: Shortcut (CSV export) — ใน Shortcut ไปที่ Settings → Import/Export → Export to CSV

• owners กลายเป็นเจ้าของ และ requester กลายเป็นผู้ขอ
• epic กลายเป็น epic ของ story
• tasks กลายเป็น task บน story ไฟล์ CSV ไม่ได้บันทึกว่าเสร็จหรือยัง จึงมาถึงในสถานะยังไม่เสร็จ
• iteration สร้างตารางรอบงาน
• คอลัมน์ started_at ถูกอ่าน ดังนั้นเวลารอบวงจรจึงใช้ได้กับ story ที่นำเข้ามา
• story ที่ถูกเก็บถาวรจะมาถึงในสถานะเก็บถาวร CSV ของ Shortcut ไม่มีความคิดเห็น

จาก GitLab

แหล่งที่มา: GitLab (CSV export) — ใน GitLab เปิดรายการ issue แล้วใช้ Export as CSV GitLab จะส่งไฟล์ให้คุณทางอีเมล

• issue ที่เปิดอยู่จะมาถึงในสถานะ unstarted ส่วนที่ปิดแล้วเป็น accepted
• Weight กลายเป็นค่าประมาณ
• ผู้รับมอบหมายกลายเป็นเจ้าของ และผู้เขียนกลายเป็นผู้ขอ
• URL ของ issue ถูกเก็บไว้เป็นที่มาของมัน
• เปิด Include milestones เพื่อให้แต่ละ milestone กลายเป็น epic หากปิดไว้ คอลัมน์ milestone จะถูกละเว้น
• CSV ของ issue ใน GitLab ไม่มีความคิดเห็น

จาก Plane

แหล่งที่มา: Plane (CSV export) หรือ Plane (JSON export) — ใน Plane ไปที่ Workspace settings → Exports

• ผู้รับมอบหมายทุกคนกลายเป็นเจ้าของ
• ความคิดเห็นตามมาพร้อมผู้เขียนและเวลาประทับ
• กลุ่มสถานะของ Plane กำหนดสถานะ issue ที่ถูกยกเลิกจะมาถึงในสถานะ rejected และถูกเก็บถาวร
• cycle สร้างตารางรอบงาน และยังคงอยู่ในรูปป้ายกำกับ Cycle: <name> ด้วย ส่วน module กลายเป็นป้ายกำกับ Module: <name>
• ไฟล์ส่งออกของ Plane ไม่มีคอลัมน์ผู้สร้าง ดังนั้นสมาชิกที่ทำการนำเข้าจะเป็นผู้ขอ Plane ไม่ส่งออกวันที่เริ่มงาน จึงไม่มีเวลารอบวงจร

จาก GitHub

แหล่งที่มา: GitHub (Issues via API) กรอกเจ้าของและรีโพซิทอรีแทนการอัปโหลดไฟล์ issue จะกลายเป็น story พร้อมผู้รับมอบหมาย ผู้เขียน ป้ายกำกับ ความคิดเห็น และรายการใน checklist ส่วนพูลรีเควสต์ ไมล์สโตน (เป็น epic) และรีลีสเป็นแบบเลือกเข้าร่วม เรื่อง token ขีดจำกัดอัตรา และอื่น ๆ อยู่ใน สร้างโปรเจกต์จากรีโพ GitHub

จากโปรเจกต์ East Agile Tracker อื่น

แหล่งที่มา: East Agile Tracker (native export) — บนโปรเจกต์ต้นทาง ไปที่ Settings → Import / Export → ดาวน์โหลดไฟล์ส่งออก นี่คือเส้นทางที่ไม่สูญเสียข้อมูล: ผู้ติดตาม ผู้รีวิว epic task ตัวขัดขวาง ลิงก์ และ Icebox กลับมาทั้งหมด และเจ้าของจะถูกผูกกลับกับสมาชิกด้วยอีเมล

หลังการนำเข้า

story เหล่านั้นคือ story ธรรมดา — เครื่องสถานะ รอบงาน และความเร็ว ใช้ได้ทั้งหมด หน้าจอเดียวกันนี้ส่งออกโปรเจกต์ได้อีกครั้งในภายหลัง เป็นรูปแบบ East Agile Tracker เพื่อสำเนาที่ไม่สูญเสียข้อมูล หรือเป็นรูปแบบของเครื่องมืออื่นใดก็ได้ ดู คู่มือการใช้งาน → Exporting a project

สร้างโปรเจกต์แล้วนำไฟล์ส่งออกของคุณเข้ามา — ตัวนำเข้าอยู่บนหน้าจอการตั้งค่าของทุกโปรเจกต์