Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Copy Crucible/FishEye to create a staging system, inc upgrade and migrate database


We currently have a FeCru (v3.3.1) in a linux VM with an Oracle database - this is the live instance.

We also have JIRA on 6.1.1 and Bitbucket 5.7

I need to enable application links between Bitbucket and JIRA and have tested this successfully by creating a JIRA staging, importing the data from a live backup and upgrading through v6.4, v7.0 and then v7.10.

However, I need to get FeCru up to v4.4 so that it can continue to integrate with JIRA.

I have created a Windows VM for FeCru to sit on but earliest version that will install on Windows is 3.4. How can I use the current live FeCru on v3.3.1 as a source to create a viable staging system running Windows, FeCru v3.4 and SQL as an external DB?

I have a db backup of the v3.3.1 but cannot just import it to v3.4 pointing at an empty SQL database?

If I use the documented migration process, what happens to the live source database on Oracle - will it be deleted?


Any pointers gratefully received!


1 answer

Hello Martin,


Welcome to the Atlassian Community!


Before we go through all of your questions, I'd like to point out that since you are running in a VM you should test your disk access speed for Fisheye just to make sure your VMs are performant enough to ensure Fisheye can run smoothly.


From what you have said, it seems that you should create a test instance on another Linux box first and upgrade that and then migrate again to a Windows box (if getting to windows is your final goal). This document for migrating Fisheye between servers should be what you are looking for to get that up and running. Be careful to not have the migrated staging instance point to your production database before upgrading (or you'll accidentally upgrade your prod database and you'll have to upgrade fully as an emergency upgrade).


When you say "but I cannot just import it to a 3.4 pointing at an empty SQL database," that is a no. You can't just import tables from a 3.3.1 backup and have a 3.4 use it. Fisheye won't start that way. This backup document should be able to tell you everything you need to do to take and restore a backup to a staging instance (again, make sure you don't restore it to the same database).


So basically, you can do this:

  1. Take a backup of your production instance
  2. Restore it to a new Linux VM at the same Fisheye version and some SQL database
  3. Upgrade that to your desired version of Fisheye
  4. Migrate to a new database type (If you would like to do so after the restore)
  5. Migrate Fisheye to the Windows VM
  6. When you are ready to make it your production you can either repeat the steps for prod, or use a reverse proxy to point to staging (now will be production)


Aaron Levinson
Dev Tools Support Engineer

Thanks Aaron, lots of useful info there and I think I now have a way forward to make progress.

By empty SQL database, I just meant a db that had been created but not yet populated via data migration.

Aaron Atlassian Team Jul 12, 2018

Ah, then yes. And I'd like to make a correction. You can restore to a different SQL database type as far as I know. I'll make that edit above as well. You should be able to take a backup of one database and restore it to another type of database. And you do have to create it first. The restore script won't create the database for you.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira

Online AMA this week: Your project management questions answered by Jira Design Lead James Rotanson

We know that great teams require amazing project management chops. It's no surprise that great teams who use Jira have strong project managers, effective workflows, and secrets that bring planning ...

197 views 1 6
Read article

Atlassian Community Events