WorkflowMigrator
Workflows are the area where the native path leaves the most rework. The WorkflowMigrator moves them and works through the typical break points along the way.
- Field, status and project references cleanly remapped
- Anything with no cloud equivalent goes into the deviation report
- Fixes error patterns beforehand, recorded as a runbook step
- Dry run before every write
- Checked against Data Center after every stage
- Nothing is written until you approve it
- A traceable final report for every run
Translated field, status and project references, rules that do not exist in the cloud, validators from add-on apps that trip up the migration assistant: the WorkflowMigrator remaps these references, maps DC rules to their cloud equivalents and writes anything with no equivalent into a deviation report — instead of quietly dropping it.
The real leverage lies elsewhere: typical error patterns that abort a migration are fixed already in preparation, and the procedure is recorded as a runbook entry for the production run. That turns the test run into the run in which the production run takes shape.
What a standard migration leaves open
After a standard migration
- Workflows break on translated references
- App validators make the assistant abort
- What is missing vanishes quietly
- The production day is a premiere
With this tool WorkflowMigrator
- Field, status and project references cleanly remapped
- Error patterns fixed beforehand
- No cloud equivalent: in the deviation report
- The production day is a repetition
From test run to production run
Every finding becomes a fixed step.
-
1
Test migration
The workflows are moved; the typical error patterns and break points surface in the process.
Verified: Every break point named, nothing quietly dropped.
-
2
Fix
The error patterns are fixed already in preparation, references remapped, rules mapped.
Verified: Result checked against the DC original.
-
3
Runbook entry
The procedure is recorded as a fixed step in the runbook for the production run.
Verified: Traceable, repeatable, not from memory.
-
4
Production run
On the cut-over day the runbook is worked through step by step — in one go, without manual interludes.
Verified: The production run is a repetition, not a premiere.
What it does
References remapped
Field, status and project references are converted from Data Center to cloud values so the workflows do the same in the cloud as before.
Rules mapped
DC rules are mapped to their cloud equivalents. What cannot be mapped does not vanish; it is named.
Deviation report
Everything without a cloud equivalent lands in a deviation report — with its location, so the rework can be done deliberately.
Fix error patterns beforehand
Typical errors that abort a migration are fixed already in preparation, not on the cut-over day.
Runbook, not memory
Every fix is recorded as a runbook entry. On the production day the runbook is worked through step by step, without actions reconstructed from memory.
Dry run and verification
Like every writing tool, the WorkflowMigrator runs a dry run first and checks the result against the Data Center original.
Common questions before migrating
What happens to rules that do not exist in the cloud?
They are not quietly dropped. Anything that cannot be mapped to a cloud equivalent lands in the deviation report with its location, so the rework can be done deliberately.
How does this help on migration day?
Every fix from preparation is recorded as a runbook step. On the production day that runbook is worked through step by step — without actions someone has to reconstruct from memory.
Are changes written live right away?
No. The WorkflowMigrator runs a dry run first and checks against the Data Center original. Writing happens only after approval.
Does it cover validators and post functions too?
It maps what has a cloud equivalent and reports the rest. Custom Groovy logic and app-specific post functions belong to the remaining-work list that the runbook and the final report set out clearly.
In control — from start to final report
Reading separated from writing
Reads come from a read-only data layer; writes go through a single controlled channel. Read access never burdens your Cloud.
A test run before every write
The dry run shows exactly what would happen. Nothing is written until you explicitly approve it.
Repeatable without risk
Every step can be run again without doing harm. An interruption is no problem, and a second run creates no duplicates.
One isolated stack per customer
All tools run on the Jira Migration Manager platform, fully separated per engagement. No mixing of data.
The final report names every item individually: repaired, to review, skipped or failed. Nothing is silently processed wrong.
Runs on the Jira Migration Manager
This tool does not stand alone. It runs on the platform that unites every tool: a read-only read layer pulls Data Center and Cloud into a versioned snapshot, and every change goes through a single, controlled write gateway.
More on the Jira Migration ManagerMore tools
Migration platform
Jira Migration Manager
The platform that brings every migration tool under one roof and makes a Jira DC-to-Cloud migration safe and repeatable: separate read and write paths, rate-limited into the Cloud, credentials encrypted, one isolated stack per customer.
- Read-only read layer and rate-limited write channel kept strictly separate
- All tools on one shared data base, chainable into pipelines
- Token-secured perimeter, encrypted keystore, one stack per customer
Assets Migration
Asset Relink
Migrates Insight/Assets to the Cloud in full: fields and contexts, AQL filters, screens and the object values on every issue. Exactly where standard tools lose the links.
- Create fields, contexts and screens in the Cloud
- Translate AQL filters from Data Center to Cloud
- Relink object values on every issue
Managed Migration
Jira Migration Helper
JCMA migrates the bulk of your data but leaves configuration broken or unmigrated. Jira Migration Helper closes these gaps module by module and, with Managed Migration, runs the right fixes for each finished project automatically — every one dry-run by default and verified against the live Cloud API.
- Repair filters, dashboards, fields, roles and permissions that JCMA leaves open
- Managed Migration: automatically run the right fixes per project as it finishes
- Web UI or CLI, every module dry-run by default and secured by the idempotent write gateway
A fit for your migration?
Describe your case in a few lines — I'll tell you honestly whether and how this tool helps.
Book a callAtlassian ends support for Data Center on 28 March 2029. If you are moving a large, deeply connected environment, plan early rather than late.