nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Merging & migration of Jira project keys

Marloes W

I could use some advice on a merging & migration issue.

The case is this:

Organization ABC bought organization XYZ.
And now they are face migration tasks. A lot.
The migration of the XYZ Atlassian stack to the ABC one is planned for June 2021 (don’t ask me why).
But a lot of teams are working together already.

And they are facing some issues:

I work with a team with a project key (let’s say TOOL) in jira.xyz.com.

But now they already want to start working in jira.abc.com under their own project and share their work with their new colleagues.

So they want to create a project - again with the project key TOOL - and add tickets to it.

So far no problem.

+++

But then it is June 2021, and the migration of the XYZ Atlassian stack will finally take place, including all Jira projects.

And also the one with the project key TOOL.

But there is already a project key TOOL in jira.abc.com.

(Luckily for us it’s in use by the same team.)

How can we merge those 2 similar keys so we don’t lose the history of the project?

I’m happy to read all your advice on this. Thanks in advance!

/Marloes

Comments

Nic Brough -Adaptavist-

It depends on what you are doing to "merge".

In the most simple case, you could just take all the issues from Tool(xyz) and import them into Tool(abc). The only thing is that the incoming issues will be renumbered as they're added to the target project.

If you don't want the xyz issues in the target abc project, you'll have to use a different project key for one of the two projects. They're easy to change, but it does mean re-keying all the issues (so you'll end up with something like TOOL and TOOLX projects)

Marloes W

Thanks Nic,

So as I understood the incoming issues will be renumbered?

So if it's currently TOOL-1234, it could be TOOL-187 in abc? That's no problem for us, we only want to keep our history (so yes we want the xyz issues in the abc project).

Nic Brough -Adaptavist-

Yes, that's right.

For a project, Jira numbers the issues on a simple flat "add one to a sequence" rule, so if you import issues into an existing project, it's going to renumber them starting with the next free number.

So imagine you've got an import with 100 issues in it, numbered between TOOL-1000 and TOOL-1500 (missing many because of delete or move). Then imagine the last issue created in the target project was TOOL-185. Assuming that the issues in the import start with TOOL-1000, then TOOL-1234, then TOOL-1235 and so-on, then, yes TOOL-1000 will import as TOOL-186, TOOL-1234 will import as TOOL-187 and so-on, up to TOOL-285 (as there's 100 coming in)

You'll lose the gaps in numbers as well as the original key, but you can import that into a field so you still have that history if you want.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

migration

cloud-migration

merge