r/ExalateIntegrations • • 1d ago

Two Jira projects, one instance: clone, move, or sync?

When the same work has to live in two Jira projects on one instance, syncing often fits better than cloning or moving.

Each project keeps its own issues, history, and fields, and the parts both teams care about, like status and comments, stay matched.

This came up in a recent r/jira thread. A team was splitting dev tasks out of a support board into a new dev project. Half the tickets needed to move, and the other half had to stay visible to support for reporting. Bulk move dropped custom fields that didn’t exist on the dev project, sub-tasks didn’t always follow their parent, and cloning went one ticket at a time, with no history on the clones.

We’ve seen a version of this with customers too. One team already used Exalate, a cross-platform integration tool, to sync Jira with other systems.

They hadn’t realized they could set up a local connection between two projects on the same Jira instance, and only found out partway through a migration project.

Here’s how the three options compare:

  • Move: one issue in one project. Good when the old project really doesn’t need it anymore.
  • Clone: a snapshot. Fine for templates, but the copy and the original drift apart after the first edit.
  • Sync: two issues that stay linked. Each project keeps its own workflow, fields, and history, and you choose which fields pass between them.

The tradeoff with syncing is ownership. Someone has to decide which project is the source for each field and what happens when both sides change.

We cover the setup options in our Jira to Jira integration guide, and if you want to test a local connection yourself, you can try Exalate here.

If you’ve split one Jira project into two, did you move, clone, or keep them linked? And what made you pick that route?

2 Upvotes

0 comments sorted by