Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Project import - 'Epic Color' and 'Epic Colour' issue


I'm trying to import a project from another servers and getting an error:

"The custom field 'Epic Color' of type 'Colour of Epic' is required for the import but does not exist in the current JIRA instance. "

I've been reading a few posts about this and I know why I'm getting this error (it's due to UK  English language being set as default on destination server and US English language being set as default on source server).

The solutions I've found involve either manually renaming the 'Epic Colour' custom field on the destination server to 'Epic Color' (or possibly changing the field name on the source server I suspect), or updating the database table.

I'm wondering if simply changing the default language on the source server to same language on destination server might also work. If I did this would it change the spelling and remove the conflict? I haven't seen this as solution to this problem but it would probably be the best solution if it works.




4 answers

1 accepted

2 votes
Answer accepted
Daniel Wong
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Feb 28, 2018

Hi @tim wilkinson

Unfortunately changing the default language on your server won't change the field name of 'Epic Color'. This is a common problem when migrating projects between Jira instances.

The quickest way (which you've mentioned above) is to unlock the field on your source instance > Rename it to match the destination instance > Lock it back > Run the Project Import.

The KB article you're after would be here -

There is an alternative way which is to hack the XML export but that can go wrong very quickly so I wouldn't recommend doing that.

Thanks - that seemed to work

Hmmm.... not working for me on my JIRA server version 8.2.1

I tried to follow the instructions here ( to unlock the field, but my H2 DB did not contain the tables in question (customfield,managedconfigurationitem, etc)

I also tried to create a new custom configuration field called "Epic Color", but could not create it with the "Color of Epic" type (the type is not listed when creating a new custom field)

Any suggestions as to how I can unlock, or create a new type, or any other suggestions?

Like ivz-viktor likes this

I was able to fix it by doing following:

1) Unlock the field 

2) Custom fields -> Action (...) > Translate 

and clear the translation



Juliman Gea
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
Aug 27, 2023

This way is working for me (v.9.6.0). Thank you

Also not working for me:  I am able to update the managed field to false, and I then have the ability to edit the field name, however the field name remains unchanged  except in the field edit screen.  SO.....I am now in the position of telling a customer that there is a fatal error and we will have to spend additional hours manually updating their source files.  

Yes, we can edit the field but the update has no effect.

This used to work for us in Jira 8.5 but now after upgrading to 8.20.1, this doesnt seem to be working.

We wound up cloning our production environment & database (the source) to the developer server then deleting ALL 400+ project spaces from the developer site.  This then made the developer site an exact replication of the source instance.  After that, importing a single project from our production site back-up file went without issue and we are now able to provide an xml file of the single project without exposing the data from every other project to unauthorized parties.  It took several weeks to do this because we have limitations of staffing & budgets as well as routine operations that can't be sidestepped.  
          Wouldn't it be great if there were a way to import the missing global elements first so the project import does not crash & burn because of innocuous or other meaningless discrepancies?  Seriously; why should a spelling variation create hundreds of hours of workaround efforts?  Further question:  Why can't a Jira project XML files be generated for export the same way it is done in Confluence?

We have the same problem here. Even new instances created with English (United States) get the "Epic Colour" field, and an older English (United States)-Jira exports "Epic Color".

You can also change the spelling of Epic Colour to Epic Color by editing entities.xml in the zipped backup file with VIM under Linux. (There may be multiple occurrences.)

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events