Switch from Unito without duplicating a single ticket
The reason teams stay on a sync tool they've outgrown isn't love — it's fear of the cutover. Turn on a second sync tool naively and every already-mirrored ticket gets mirrored again. Migration mode exists to make that fear obsolete.
The duplicate problem, and how migration mode solves it
If two projects have been synced by Unito for a year, they already contain hundreds of ticket pairs that belong together. A new sync tool that doesn't know about those pairs sees "unsynced" tickets on both sides and starts creating mirrors — instant duplicates, twice the mess you started with.
Ticketize's migration mode runs a scan before the rule activates. It looks for the traces a previous sync tool leaves on mirrored tickets — attribution footers on comments, sync labels, link fields — and reconstructs the existing pairings from them. Each detected pair is proposed in the Sync Inbox; you accept (or reject) them, and accepted pairs are adopted as sync links. From then on Ticketize updates the existing mirror instead of creating a new one. Only genuinely unpaired tickets ever get fresh mirrors.
Step by step: cutting over in an afternoon
- Connect both Jiras. Authorize each Atlassian site via OAuth on the Integrations page — no API tokens, no Marketplace install. (Docs.)
- Create the sync rule with migration mode on. Pair the same source and target projects Unito was syncing, map your statuses, priorities, types, and assignees in the wizard, and enable the migration-mode toggle on the Review step.
- Review the proposed adoptions. The scan surfaces detected pairs in the Sync Inbox. Skim, accept, done. Anything ambiguous is left for your judgment — nothing is linked behind your back.
- Pause the Unito flow. Before the Ticketize rule goes live, pause or delete the old tool's flow for this project pair so two engines aren't writing to the same tickets.
- Enable the rule. Adopted pairs keep syncing from their current state; new tickets mirror normally. Your history — comments, attachments, past status changes — stays exactly where it was.
What carries over, what doesn't
- Existing mirror pairs — adopted, not recreated. No duplicates.
- Historical comments and attachments — untouched, including any Unito attribution footers on old comments. Ticketize doesn't rewrite history.
- New activity — synced by Ticketize with your chosen attribution style (preamble, footer, or none on paid plans), through your own field mappings.
- Unito's flow configuration — doesn't carry over; you rebuild the mapping once in the wizard. For a Jira-to-Jira pair that's a few minutes of explicit choices, and the wizard pre-proposes status mappings by name and category.
The same flow covers Exalate and Backbone Work Sync mirrors — the markers differ, the adoption logic is the same. And if you ever leave Ticketize, the courtesy is symmetric: a one-click clean exit strips every marker we added.
What happens to Unito's footers on old comments?
They stay. Ticketize doesn't rewrite historical comments — old mirrored comments keep whatever attribution Unito added. New comments synced by Ticketize carry the attribution style you pick per rule: preamble, footer, or none (paid plans).
Can I run Unito and Ticketize at the same time during the transition?
Briefly and carefully. Two tools writing to the same ticket pair can echo each other's changes back and forth. The safe pattern is: pause Unito's flow for the project pair first, then enable the Ticketize rule. Migration mode adopts the existing pairings either way, so there is no need for an overlap period.
What if some mirrors aren't detected automatically?
Anything migration mode can't match by markers shows up as a discovery proposal you can accept or reject in the Sync Inbox — including pairing suggestions based on matching content. You can adopt remaining pairs by hand there; nothing is created behind your back.
Does this work for Exalate and Backbone mirrors too?
Yes. Migration mode detects markers from other common sync tools, and the Sync Inbox adoption flow is tool-agnostic — if two tickets are already a mirror pair, Ticketize can adopt them regardless of which tool created them.
How long does a cutover take?
For a typical project pair: connect both Jiras (minutes), create the rule with migration mode on the Review step, let the scan propose adoptions, review them in the Sync Inbox, pause the old tool, enable the rule. Most teams finish in an afternoon.
Ready to switch without the mess?
Migration mode adopts your existing mirrors and the Sync Inbox keeps you in control of every pairing. From $3/month.
No credit card required · Free tier included · Set up in minutes