Editing Jira Workflows After DC to Cloud Migration

Your Data Center workflow had a validator that blocked anyone without approval from moving a ticket. In Cloud the same transition now fires with no check at all, and the migration report still says the workflow moved across.

Workflows are where migration checks quietly fall through the cracks. This guide covers what arrives intact, what needs a review, and how to edit a workflow in Cloud without breaking the transitions people rely on every day.

How Workflows Arrive After Migration

A Jira workflow is a set of statuses joined by transitions. Conditions decide who can take a transition, validators decide whether the transition is allowed to complete, and post functions run after it fires. A workflow scheme links workflows to issue types within a project, and a status can be shared across several workflows in the same scheme.

JCMA moves the workflows, the statuses and the schemes. What it does not promise is that every automation layer around them maps cleanly. Properties, triggers and any logic that leaned on a Data Center only app are the usual casualties.

What to Review After the Move

Conditions and validators

Conditions such as "only the reporter" or "only users with a permission" and validators such as "field required" mostly carry across, but any that referenced a custom field by name can now point at a field that, after a re-run, was duplicated with a "(migrated)" suffix.

Workaround: open each transition and confirm every condition and validator still targets the right field ID, not just the right name. If two fields share a name, the wrong one may be selected.

Post functions that write to fields

A post function like "Update Issue Field" sets a value on the issue when the transition fires. After migration its target may be a "(migrated)" copy, so new transitions write into the duplicate while your reports read the original.

Workaround: clean the duplicate fields first, then re-point the post function at the surviving field. Doing the field cleanup before the workflow edit saves you from making the same change twice, see merging duplicate custom fields safely.

Workflow properties and triggers

Properties that tuned behavior, and triggers tied to scheduling or an app, are the least likely to survive intact. A workflow that depended on a Data Center app for a special trigger may arrive with the transition present but the trigger gone.

Workaround: export the property list from the source and compare it against Cloud after the run. Where a property has no equivalent, rebuild the behavior with a native automation rule instead of leaving the transition naked.

Statuses shared across workflows

A status used by more than one workflow behaves differently in Cloud. Editing a shared status can ripple into other projects, and some workflows cannot be edited directly once they are shared.

Workaround: note which statuses are shared before you edit. If a change needs to stay local, copy the workflow and repoint the scheme rather than editing the shared original.

Editing a Workflow in Cloud, Step by Step

Cloud handles workflow changes through a draft, which is the safety net Data Center never gave you. Work in this order.

1. Open the project, go to Project settings, then Workflows, and pick the workflow to change.
2. Click Edit to open the workflow editor, Cloud creates a draft you can see but users cannot.
3. Adjust the transitions, and review every condition and validator on each one.
4. Step through each post function, especially anything that updates an issue field.
5. Publish the draft, the draft replaces the live workflow and users see the change.
6. Test a full transition on a scratch issue and confirm the checks you set actually fire.

For anything larger than a tweak, build a fresh workflow and reassign the workflow scheme instead. That keeps the old workflow intact until you are sure the new one behaves, and lets you roll back by swapping the scheme again.

Resources

• What Does JCMA Actually Migrate? A Field-by-Field Breakdown
• JCMA Post-Migration Checklist: What to Clean Up After Migrating
• What Is JCMA? Why Jira Cloud Migration Assistant Creates Duplicate Fields
• How to Remove the (migrated) Suffix from Jira Custom Fields
• Atlassian: Troubleshoot migration with Jira Cloud Migration Assistant

Half the workflow fixes on this list wait on one job, getting the duplicate fields out of the way. Migration Helper scans for "(migrated)" fields, matches each to its original, compares the schema, and merges in one click, filling the original only when it is empty so Cloud native data is never overwritten. It runs entirely on Forge, and teams of 50 or fewer users can scan and merge free. Install Migration Helper from the Atlassian Marketplace.