I need clarification on migrating JIRA 4.1 to new server?

Elijah

We are not upgrading JIRA to a new version. We are trying to replicate the system into a test server to have an exact match of what is in production.

To split a JIRA instance, (information comes from JIRA041)

1. Backup your database, using your database backup procedures, and verify the backup.
2. Backup your attachments directory and verify the backup.
3. Install JIRA on your new server. NOTE:
   • The JIRA version number on your new server must be the same as (or higher than) the version number on your existing server.
   • Do not use the same JIRA home directory for the two JIRA instances. Specify a new JIRA home directory for the JIRA on your new server.
   • Do not connect the two JIRA instances to the same external database instance.
4. Create an XML file from your existing JIRA server, as described in Backing up data.
5. Import the XML file into your new server, as described inRestoring data.
6. Copy the attachments directory from your existing server to your new server, and configure your new server to use its own directory (for details please see Enabling File Attachments).
7. At this point you should have two JIRA instances with the same users, projects, issues and attachments. Log into both instances and perform some random searches to verify that the data is identical in both instances.
8. Delete the non-required projects from each JIRA instance.

Okay so here are the things I am trying to understand regarding the instructions above in the order as they are listed on the page.

1. If I am moving this to another server which is completely detached from the current server, WHY do I need to use a different JIRA home directory this does not make sense to me?
2. I'm assuming that the errors that I have while trying to import the XML where the date format is not valid is in part due to the use of the XML where in the documentation it states "XML backups are not guaranteed to be consistent..."
3. Would deleting the non-required projects from JIRA remove the issues and attachments?
4. Is there a known script to pull out all the data from the JIRA database that are relevant only to the users, projects and the JIRA environmental configurations?

One other question.

For us to replicate the system and the project to another server we would want to do the above and not just try to restore a project right? Because the JIRA instance has been heavily customized both in source and in the use of custom fields.

 

Thank you for your time in reading my post.

 

David Di Blasio_f9zfaa

Hi Elijah,
Here's my 2 cents on your migration questions.

If I am moving this to another server which is completely detached from the current server, WHY do I need to use a different JIRA home directory this does not make sense to me?

You wouldn't need to. This is just a warning that you could overwrite your data if you installed JIRA on the same server as your production server.

I'm assuming that the errors that I have while trying to import the XML where the date format is not valid is in part due to the use of the XML where in the documentation it states "XML backups are not guaranteed to be consistent..."

This really depends on the errors you're receiving. Can you post a log snippet so we can get an idea of what the errors are?

Would deleting the non-required projects from JIRA remove the issues and attachments?

Yep, this is the behavior I would expect.

Is there a known script to pull out all the data from the JIRA database that are relevant only to the users, projects and the JIRA environmental configurations?

Not that I'm aware of.

For us to replicate the system and the project to another server we would want to do the above and not just try to restore a project right? Because the JIRA instance has been heavily customized both in source and in the use of custom fields.

What I would actually recommend to do in this circumstance is set up a staging server to run the import against. Then you can go through and delete anything you don't want, and then export/import to your production environment. This would be safest and cleanest way I can think of to get to the end goal.