How to upgrade from JIRA 7.2.3 (Oracle-based) to a different JIRA 8.13 (SQL Server-based)

[Michael Schumacher]

Hello,

we have one "old" (O) server with JIRA 7.2.3, which is Oracle-based. Due to needed OS upgrade, we decided to setup a "new" (N) JIRA-system now using SQL Server.

On N we installed 7.2.3, imported configuration of O and upgraded to 8.13. This went well.

Currently our developer still work with O and we cannot set this system offline during working hours.

Our plan is now to run a backup on O and import it on N. However when trying it, we again see the configuration items of O in N, which is unwanted.

So how to proceed without the same efforts (meaning: without needing to upgrade N again from 7.2.3 to 8.13) more simplified?

Is this possible?

Thanks in advance.

[Nic Brough -Adaptavist-]

I do not understand this bit:

"Our plan is now to run a backup on O and import it on N. However when trying it, we again see the configuration items of O in N, which is unwanted."

But the whole point of your upgrade and migration IS that you want the system from O upgraded and moved to N.

So what is "unwanted"?

[Michael Schumacher]

Currently N is running in "test mode". Just 2 developers are testing, whether N is still able to work as O. But in the meantime the data in O will be updated due to ongoing LIVE projects, whereby N stays in the current state.

So the day will come when N will supersede O, but that day we need to have the data migrated from O to N beforehand.

Which is not working as one still see configuration settings of O in N as per today´s test (i.e. hint to Oracle database)...

[Nic Brough -Adaptavist-]

That's not going to happen.  You have two separate systems.  One is a copy of the other at a point in time, and hence they are going to diverge.

Unless you can build up some form of synchronisation that pushes an acceptable level of data updates from O to N real time, plus some way to work out what "testing" you are doing in N can be deleted or got rid of (bearing in mind that proper testing will have affected your actual production data and hence would need rolling back), you are going to need to go through:

1. Stop activity on O
2. Migrate data to N
3. Upgrade data on N
4. Start activity on N

2 and 3 could be reversed (upgrade on O, migrate to N), but I would recommend the order above, as if something goes wrong, your "roll back" is just "go back to using O"