How can I migrate issue-tracking projects without losing their workflow?

Start with an inventory of behavior, not a list of status names. For each issue type, record its workflow, the statuses it can occupy, and the allowed transitions between them. Then document each transition’s conditions: who may use it, what information it asks for or checks, and what actions it performs afterward.

For example, a project might have “Open,” “In review,” and “Done.” That label match is not enough if only certain people can move an item to review, a review requires a decision field, or completing the work triggers another action. Jira Cloud describes workflows as defining movement between statuses, with transitions specifying the next statuses; its transition-rule categories include restrictions, input requests, validation, and post-transition actions. [S2] Use these categories as a comparison prompt, not as proof another product supports the same features.

Use one row per source issue type and workflow path, and keep the original and proposed destination names side by side. Add a separate entry for each transition so differences remain visible. A compact template is:

Issue type | Source workflow | Source status/transition | Rule or required input | Destination equivalent | Gap/action | Test case

Example, with hypothetical names: Bug | Defect flow | In review → Done | Reviewer decision required | Review → Complete | Rebuild decision check; verify supported mechanism | Try without decision, then with decision.

Include priorities and how they are associated with issue types or projects, too. If a destination uses different labels, write down the intended meaning rather than treating similar words as equivalent. Mark each item as “mapped,” “rebuild,” “manual workaround,” or “not needed,” and assign someone to resolve every gap before cutover.

No. Verify the exact migration route and its current supported-item list. For the specific Jira Server or Data Center to Jira Cloud route documented for Jira Cloud Migration Assistant, the listed items include issue types and schemes, workflows and workflow schemes, statuses and transitions, priorities and priority schemes, and issue data such as issue type and status. The same documentation lists workflow triggers and properties among items that are not migrated. [S1]

That is evidence about that Jira route only; it does not establish what another app, migration tool, or later version will transfer. Nor does a listed workflow mean every rule behaves identically in the destination. Compare the documented exclusions with your inventory, confirm current rule support for your route, and plan explicit rebuilds or alternatives for anything not covered.

Agree on expected outcomes first, then test in the destination with representative items for each important issue type and path. Include ordinary transitions and edge cases: a user who should be allowed, one who should not; required information omitted and supplied; validation that should block a transition; and any expected follow-up action. Record expected and actual results, the test item, and the person who checked it.

For instance, if a hypothetical “Ready for review” transition requires a reviewer decision, test both an attempt without the decision and one with it. Confirm the first is blocked if that is the intended behavior, and the second reaches the intended status. Repeat for priorities and issue types, and check that migrated issues land in appropriate statuses. Treat failures as mapping or rebuild work, not as harmless label differences. Do not cut over until each high-impact gap has an owner and a verified disposition.