AutomationMigrator
Your automation rules only partly survive the move to the cloud — and some never fire again without anyone noticing. AutomationMigrator compares every rule against its Data Center original, repairs it via API, and verifies that it actually runs.
- Repair scope, field references, triggers and owner per rule
- Detect silent rules that exist but never fire
- Show every repair as a dry run first, then write on approval
- Dry run before every write
- Checked against Data Center after every stage
- One isolated stack per customer
- The final report names what was skipped, too
Jira automation rules only partly survive the move to the cloud. Project scope references, field IDs, status values, trigger formats and the executing owner break during the transfer — and a rule that looks correct in the editor still does nothing because of it. The most insidious case is the silent runtime no-op: the rule exists, it looks complete, but it never fires. The defect only surfaces weeks later, when an issue goes unassigned or an SLA fails to start.
AutomationMigrator analyses every migrated cloud rule against its Data Center original and repairs it via the API — scope, field references, trigger and action schemas, owner and actor. Behind it sits an extensible catalogue of error classes. The core works deterministically, with no AI and no API key; an AI-assisted multi-eyes verification runs as a separate gate before activation. Every conversion is an auditable artefact, a dry run shows each planned change in advance — and you press the approval button.
What a standard migration leaves open
After a standard migration
- Migrated rules point to the wrong project scope or dead field IDs
- A rule exists, looks correct, but never fires
- Defects only surface weeks later in day-to-day work
- Nobody knows what a tool changed in the rules
With this tool AutomationMigrator
- Scope and field references are resolved to the cloud in a type-aware way
- The executing component version is correct and the rule truly runs
- Every break is named during the scan and caught before activation
- Every conversion is an auditable artefact, approved by you
In three verified steps
AutomationMigrator writes nothing blindly. First it scans against the Data Center original, then it computes the repair and shows it as a dry run — it writes only on your approval, and then verifies against cloud rules that actually execute.
-
1
Scan against the original
AutomationMigrator places every cloud rule next to its Data Center original and identifies the error classes introduced by the move. Rules that were never migrated, or arrived as a partial JCMA copy, become visible too.
Verified: every deviation named and assigned to an error class
-
2
Repair as a dry run
From the identified error classes the tool computes the required repair — scope, field references, trigger and action schemas, owner and actor. The dry run shows each planned change in detail before anything is written to the cloud.
Verified: every planned change visible and approvable in advance
-
3
Write and verify
After your approval, AutomationMigrator writes the repair through the write gateway and verifies the result against cloud rules that actually execute. Only this check shows whether a rule is merely created or genuinely fires.
Verified: every rule checked against a cloud rule that truly executes
What it does
Compared to the original
AutomationMigrator places every cloud rule next to its Data Center original and finds what broke during the move. It checks scope, field references, trigger and action schemas, and the executing owner. So you see not just that a rule exists, but whether it matches what it used to do.
Catching silent rules
Some rules exist, look correct and still never fire — a silent runtime no-op that only surfaces weeks later. AutomationMigrator detects this state before it does damage. The benchmark is the correct component version per action type, derived from real cloud rules that actually execute.
Catalogue of error classes
Every typical break has its own error class — from wrong project scope through dead field references to SLA and owner defects. AutomationMigrator assigns each finding to a class and knows the matching repair for it. The catalogue is extensible, so newly recognised patterns are added rather than fixed by hand.
Type-aware field resolution
Two fields with the same custom field ID can have completely different schemas in the cloud. AutomationMigrator tells them apart and resolves every reference in a type-aware way, instead of blindly swapping one ID for another. That keeps a rule off the wrong field just because the number happens to match.
Multi-eyes verification
The repair core works deterministically, with no AI and no API key. An AI-assisted multi-eyes check then runs as a separate gate before activation and reviews every conversion once more. Both paths are separate, so the result stays traceable and the AI changes nothing unnoticed.
Dry run and audit trail
Before every write, a dry run shows each planned change in detail. Every conversion is recorded as an auditable artefact, so it stays clear what was changed and why. You can run it from the web UI with a live console and token auth, or from the CLI with scan and fix.
Common questions before migrating
How do I know whether a rule truly runs or is merely created?
A rule can look complete and still never fire — a silent runtime no-op. AutomationMigrator checks the executing component version per action type and derives the benchmark from real cloud rules that actually run. That lets the tool tell "created" apart from "truly running".
Does an AI change my rules without me being able to control it?
No. The repair core works deterministically, with no AI and no API key. The AI runs only as a separate verification gate before activation and writes nothing itself. Every change is shown beforehand as a dry run and written only on your approval.
What happens to fields that share an ID but have a different schema?
The same custom field ID can point to a completely different field in the cloud. AutomationMigrator resolves field references in a type-aware way and tells these cases apart, instead of blindly translating an ID. That keeps no rule on the wrong field just because the number matches.
Can I also bring along ScriptRunner scripts and partial JCMA copies?
Yes. The scan-stubs command detects partial JCMA copies that only half arrived, and convert prepares ScriptRunner scripts as conversion tasks. Assets-related lookups are handed over to Asset Relink, so those references are resolved correctly too.
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
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.