CannedResponseMigrator
Canned responses are in daily use in support and easily overlooked in a move. The CannedResponseMigrator brings them across in full, along with the cleanup a plain text move does not do.
- Canned responses across all service projects
- Idempotent: a second run creates no duplicates
- Placeholders remapped, references redirected to the cloud
- 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
The CannedResponseMigrator pulls all canned responses across every service project from the Data Center and creates them in the cloud. The import is idempotent: existing titles are skipped, and a second run creates no duplicates.
It does more than move text. DC placeholders are remapped to the corresponding cloud variables and character-identical duplicates are consolidated. If Confluence was migrated in parallel, an optional mapping redirects the references in the response texts to the new cloud pages instead of letting them point nowhere. Whatever cannot be mapped is left unchanged and reported as an open item.
What a standard migration leaves open
After a standard migration
- Canned responses left behind in Data Center
- Placeholders do not work in the cloud
- References point nowhere after the move
- A second run creates everything twice
With this tool CannedResponseMigrator
- Transferred to the cloud in full
- Remapped to cloud variables
- Redirected to the new cloud pages
- Idempotent, no duplicates
Four stages
Export, mapping, preview, import.
-
1
Export
All canned responses are pulled across every service project from the Data Center.
Verified: Complete across all projects.
-
2
Link mapping (optional)
If Confluence was migrated in parallel, the move list is read in and a mapping of old to new pages is built from it.
Verified: References then point to the cloud, not nowhere.
-
3
Preview
The preview shows in full what would be created, without writing.
Verified: Nothing is created without approval.
-
4
Import
The templates are created idempotently, placeholders remapped, duplicates consolidated.
Verified: A second run creates no duplicates; open items reported.
What it does
All service projects
The export pulls the canned responses across every service project of the Data Center, not just a single one.
Idempotent import
Existing titles are skipped; a second run creates no duplicates. The import can be repeated safely.
Placeholders remapped
DC placeholders are remapped to the corresponding cloud variables so the responses insert the same as before.
References redirected to the cloud
If Confluence was migrated in parallel, the references in the responses then point to the new cloud pages instead of nowhere.
Duplicates consolidated
Character-identical duplicates are consolidated instead of being created multiple times.
Open items reported
Whatever cannot be mapped — such as references to knowledge-base articles or embedded images — is left in place and explicitly reported as an open item.
Common questions before migrating
Does a second import create duplicates?
No. The import is idempotent: existing titles are skipped. You can repeat it safely.
Do the placeholders work in the cloud?
Yes. DC placeholders are remapped to the corresponding cloud variables so the responses insert the same values as before.
What happens to references to Confluence pages?
If Confluence was migrated too, an optional mapping redirects the references to the new cloud pages. Whatever cannot be mapped is left in place and reported as an open item.
Do I see beforehand what gets created?
Yes. The preview shows in full what would be created before anything is written.
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.