Epic not Epic

[Brian Michelsen]

Hi,

After migrating from one database to another, Epic is no longer Epic, meaning that it seems that another issue type called "Technical debt" is set for context on Epic Name and Epic Colour, and also appears in Epic Link. How do I change it back to Epic? We have tried to unlock the fields and changing the context to point to the issue type Epic, but when Jira is restarted it's back to "Technical debt".

[Brian Michelsen]

I have more information. It seems that the initial installation is very old, and the issue type id's in the database is 1,2,3 etc. Epic issue type is id 11, but according to Atlassian the newer installations the Epic issue type id should be 10000, which is the id number of the "Technical debt" issue type.

When that said, we have a one environment with the same id's and Epic works as it should, but not the other.

I have also contacted Atlassian and working with them, but I still want to get some ideas of what we can do. Somehow the Epic becomes an Epic so it can be used in Epic Link.

[Nic Brough -Adaptavist-]

This is definitely an Atlassian problem now.

Your migration should have kept all the numbers and relationships, and I am very stuck on how this could have happened.  An XML migration should (and always has for me) result in a new system that is identical to the old.

I have moved many old installs to newer systems and not had this problem.  I can point at several large and old systems currently running the latest (LTS) version of Jira where the Epic id is a hundred and eleventy twelve or thereabouts.  As it was on the source system.

Much as the community, and partners, might be able to help, this is very very much something where you've done the right thing by asking Atlassian.  (As a partner, I think I'm obliged to say "ask us for help" too, if Atlassian get stuck)

[Nic Brough -Adaptavist-]

How did you "migrate" from one database to another?

I ask because this sounds like you exported and imported projects, not the database, OR you only "migrated" part of the tables.

[Brian Michelsen]

Bad phrasing... We did a XML export from a instance with a MySQL and then pointed to a PostgreSQL and did a XML import.

This is how Atlassian recommends migrating between databases.

[Nic Brough -Adaptavist-]

Ok, great.

This method means all the values of everything should be identical (not necessarily the same bits in the databases).

Which means it is very worrying that your config has changed.

How exactly did you do the import into the Postgres database?  I mean, did you do something like:

1. Export
2. Create a new empty database in Postgres
3. Stop Jira
4. Remove the dbconfig file 
5. Start Jira
6. Run through the setup, using the new postgres database
7. Log in as the new admin
8. Run the import

Did you do it differently to that?

[Brian Michelsen]

Yes it was like that, and everything else works. It's only the the epic function is on a wrong issue type, and not Epic.

[Brian Michelsen]

Any idea how to change the epic marked from one issue type to another?

[Nic Brough -Adaptavist-]

The problem here is that it's unlikely to be just that one problem.  Something went wrong and has corrupted your data.

[Brian Michelsen]

There's no going back as the instance has been used all day, so we have to take one issue at a time and fix it. We haven't noticed anything else yet.

[Nic Brough -Adaptavist-]

I'm afraid there's no way to fix this without going back and looking at exactly where your migration went wrong.

You could be spending years finding and fixing these problems, and now you've started using a corrupted database, it's unlikely that you'll ever be able to repair it because people will be adding corrupted data to it.