CustomFieldMerger
Grown instances often carry the same information in several fields. After the migration is the right moment to clean up — the CustomFieldMerger does it in a controlled way, without anything tipping over.
- Duplicate fields merged safely
- All dependencies found beforehand and followed up
- Every write step with a dry run and a typed confirmation
- 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
Merging duplicate fields is delicate because filters, boards, automation and screens depend on fields. The CustomFieldMerger covers the full lifecycle in five stages: from analysing all dependencies through the merge to the cleanup.
Every write step starts as a dry run and additionally requires a typed confirmation phrase — a deliberate break in the flow so a field merge cannot be triggered by a misclick. Retiring the source field moves it to the trash and stays reversible.
What a standard migration leaves open
After a standard migration
- The same information in several fields
- A merge breaks filters and automation
- A misclick triggers the merge
- Once deleted, gone for good
With this tool CustomFieldMerger
- Duplicate fields cleanly merged
- Dependencies found beforehand and followed up
- Typed confirmation before every write
- Source field in the trash, reversible
Five stages
From tracking down to reversible cleanup.
-
1
Analyse
Find candidates, plan the merge and track down all dependencies: filters, boards, automation rules, screens, schemes, service-management references.
Verified: A complete dependency picture before the first write.
-
2
Prepare
Set up the target field, align option values and temporarily pause affected automation rules.
Verified: No rule fires in the middle of the switch.
-
3
Merge
Transfer values, check the result, empty the source field — with restore from backup if needed — and reactivate the rules.
Verified: Dry run and typed confirmation per write step.
-
4
Follow up dependencies
Repair filters, correct rules and output a checklist.
Verified: Nothing points nowhere after the merge.
-
5
Cleanup
Retire the source field and move it to the trash.
Verified: Reversible, not final.
What it does
All dependencies found
Before the merge, filters, boards, automation rules, screens, schemes and service-management references are tracked down.
Rules paused temporarily
Affected automation rules are paused before the switch so they do not fire in the middle of it, and reactivated afterwards.
Values transferred safely
The values are transferred to the target field and checked; the source field is emptied, with restore from backup if needed.
Dependencies followed up
Filters are repaired, rules corrected and a checklist output, so nothing points nowhere after the merge.
Typed confirmation
Every write step starts as a dry run and requires a typed confirmation phrase. No merge by misclick.
Reversible cleanup
The source field is retired and moved to the trash — reversible, not final.
Common questions before migrating
What happens to filters and automation that depend on the field?
They are tracked down beforehand and followed up after the merge: filters repaired, rules corrected, a checklist output. Affected rules are paused during the switch.
Can a merge happen by accident?
No. Every write step starts as a dry run and additionally requires a typed confirmation phrase — a deliberate break so nothing is triggered by a misclick.
Can a merge be undone?
The source field is not deleted for good but retired and moved to the trash. When emptying there is also a restore from backup.
When should fields be merged at all?
After the migration is the natural moment, because you are cleaning up anyway. The CustomFieldMerger makes this risky step controlled and traceable.
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.