Jira-to-WorkThroughLine checklist for a controlled cutover

This checklist has one precise purpose: moving active product work from Jira to WorkThroughLine. It is not a Jira Data Center → Jira Cloud guide and it is not a migration guide for the Smart Checklist Marketplace app. For a Data Center assessment, start with the options and timeline to end of life in 2029; for a move within Atlassian, use the Jira Cloud Migration Assistant documentation. Use the app vendor’s guidance for Smart Checklist.

Download the checklist as CSV. Open it in Sheets or Excel, assign an owner to each row and use the final column for evidence: a report URL, item count, decision or reason for an exception.

Before scheduling cutover, run the free Jira migration readiness assessment and download the source-to-target reconciliation template. Answers and the CSV stay local; the assessment does not replace a pilot.

1. Name the owner, scope and cutover moment

A migration without one owner becomes a chain of partial decisions. Someone must own the project list, mappings, unresolved warnings and the final go/no-go decision.

Before the first export, record:

• the migration owner;
• active Jira projects and JPD spaces in scope;
• what remains archive-only;
• who signs off product, engineering and administration;
• the date and exact time of the change freeze;
• where new work starts after that moment.

Do not move everything automatically simply because it exists. An old closed project can remain in the preserved Jira export when it has no operating value in the new system.

2. Preserve an untouched source before cleanup

Create an export with all available fields and preserve the original file without opening and resaving it. This is the audit copy used for later reconciliation. If you create a cleaned working version, keep it as a second file.

Atlassian states that a complete Jira Cloud backup can include work items and system/custom fields, sprint data, users, comments and attachments, but not automation flows or third-party app data. A CSV move into another product is not the same as a full site backup, so inventory these separately:

• Marketplace apps and their private data;
• automations and workflow configuration;
• dashboards, filters and permission schemes;
• physical attachments versus attachment references;
• integrations that depend on Jira IDs.

3. Run preflight without writes

Run WorkThroughLine preflight first. Its job is to show what the importer recognized before anything is written:

• projects and item counts;
• statuses, types and priorities;
• users that can and cannot be mapped;
• sprints and missing dates;
• comments, relationships and additional fields;
• warnings and unsupported values.

Compare the preflight totals with the source scope. If they differ, do not continue merely because no red error appears. The difference needs an explanation.

This principle is not unique to WorkThroughLine. For its own migrations, Atlassian recommends running pre-migration checks several days before production and completing a test migration before the final run. Its pre-migration checklist is a useful additional source for large or complex instances.

4. Map meaning, not only labels

A Ready for QA status does not need an identically named destination. The question is what it should mean in the process after migration. The same applies to custom issue types, priorities and users.

For every mapping, record:

• the source value;
• the target value;
• the decision owner;
• why several source values collapse into one target value;
• any accepted loss of detail.

Review inactive and unavailable users separately. Leaving an item explicitly unassigned is safer than attributing historical ownership to the wrong person.

5. Choose a representative pilot project

The smallest project is often a poor pilot because it contains none of the hard edges. Choose one with a normal mix of:

• epic/parent/subtask structure;
• an active and at least one historical sprint;
• comments by different authors;
• blocking, related or duplicate links;
• custom statuses or priorities;
• some unassigned or inactive users;
• JPD context, when applicable.

The pilot is not a demo that the importer can run. It is an attempt to expose a source-versus-result difference while it is still cheap to fix.

6. Reconcile instead of only browsing

Opening three random tickets is not enough. Build a small control table:

Check	Source	Result	Decision
Open items by project
Items by status
Epics with children
Items in the active sprint
Items with comments
Items with blocking links
Unassigned users

Then open representative items and inspect content, comment authors and dates, parent links, sprint and original Jira key. Record accepted limitations explicitly instead of leaving them in the migration owner’s memory.

7. Complete the final cutover

After the pilot passes:

1. remind the team of the change-freeze time;
2. stop new work and comments in Jira;
3. create and preserve the final export;
4. run the final import;
5. review the report, warnings and conflicts;
6. repeat the agreed reconciliation checks;
7. announce WorkThroughLine as the new source of truth.

Stable Jira identities prevent a repeated import from creating another copy of the same item. If someone manually changed an already imported item, safe mode skips it and reports a conflict instead of silently overwriting the change.

8. Treat the first few days as aftercare

Agree on a short period in which one owner reviews exceptions and team questions every day. Jira and the final export remain available as read-only references according to internal policy, but new work does not split across two sources of truth.

The checklist is complete when the team no longer asks “where do I enter this now?”, not when the import job turns green.

Open the detailed WorkThroughLine import instructions or review what is migrated, mapped and left outside the import.