upgrade/migrate, jira 6.1.4/mysql/expired to 7.0.11/postgresql/current

[Richard Hector]

I'm trying to upgrade from an old 6.1.4 instance. The old instance still has an old licence installed, but we have a new(er) one that hasn't been used before (AFAIK).

I've followed what I think are the right steps (not showing the precautionary ones):

• perform xml backup on old server, stop old server
• unzip 7.0.11 on new server
• rsync 6.1.4 home to new server, delete dbconfig.xml
• create new empty (postgresql) database
• run config.sh to set jira home and database
• update server.xml connector for proxy server, and context path
• start jira and import backup, supplying new licence key.

At this point, I get a 500 error, from which I can get a large java stack trace, starting like this:

java.lang.RuntimeException: javax.servlet.ServletException: com.google.common.util.concurrent.ExecutionError: com.google.common.util.concurrent.ExecutionError: java.lang.AbstractMethodError

The postgresql log shows:

2018-06-17 18:47:24.244 NZST [27925] jira@jira7.0 ERROR: schema "entity_property" does not exist
2018-06-17 18:47:24.244 NZST [27925] jira@jira7.0 STATEMENT: DROP INDEX entity_property.entityproperty_identiti

Any ideas what's causing this? Do I need to install the new licence on the old server before upgrading?

Thanks,

Richard

Edit: It looks like it's failing to sync with crowd on localhost:8095, which makes sense because it isn't there. But I can't see where that's configured - is it just the default? How can I change the crowd url before starting jira? I need to (temporarily, at least) point it at crowd on the old server.

Richard

[Nic Brough -Adaptavist-]

It's because you've connected a partially configured system.  Your list of things you've done is broadly right, but the "rsync" is done too early.  You've effectively copied the application configuration over and then pointed it at an empty database, and that app config is where the crowd settings are from.

What you wanted to do was get the new Jira up and running with no data, save the dbconfig for the new database, then do the rsync, replace the copied dbconfig with the saved one, and then import.

[Richard Hector]

Hmm. I don't think I've seen a process like that in any of the (many) docs I've found yet :-)

I'm mostly trying to follow https://confluence.atlassian.com/adminjiraserver070/migrating-jira-applications-to-another-server-749382719.html

I found the crowd settings in the database (searching through pg dump), but since I couldn't easily intervene between importing the xml backup and attempting to connect to crowd, I resorted to editing the xml and updating the zip file. That seems to have resolved that issue, but I don't think it was the core one.

Using your suggested process, I'd have to set up Jira with dummy data, then overwrite it later with the import, right? And I'd still have to edit the xml before the import, to avoid losing the crowd connection. Unless there's more going on than I can see, I don't see anything to be gained (but happy to be put straight)

Incidentally, when I get the 500 error, in the "Technical details" I get "Log's referral number" - should I be able to find that number in a log file somewhere? I've looked, but no joy yet.

(there's no chat service available, right?)

[Nic Brough -Adaptavist-]

Correct, setting it up with dummy data will happen, but that dummy data would be destroyed when you get the old data in, and it's not a huge amount of data either - a skeleton setup plus a starter project that you don't care about.  The aim there is to get a fully working proven Jira running before importing your setup and data.

The crowd thing is in the database, yes, but in the user directories, from which you can simply edit/remove the directory after import.

The log referral number is just a string that is generated to allow you and Atlassian to find it more easily later if I understand correctly.  (it's mostly in case someone raises several of them, it's handy to have a clean unique id for them)

[Richard Hector]

Thanks for your assistance, and apologies for not accepting your answer.

I know you're a community member, and so can't be held accountable for Atlassian, but I'm uncomfortable accepting an answer that goes against the official docs for the upgrade, and doesn't explain why they didn't work (which you obviously may not know). I should have asked for more details if I wanted them.

I've been struggling with this upgrade project (Confluence works, Jira was causing me grief, Crowd not started) a while now, and this morning the straw broke the camel's back, and I'm not working on it any more. Among other things, that means I can't test your procedure, which is the main reason for not accepting it.

Again - sorry about that. Not your fault.

I'm returning to the land of Free Software, where I'm happier ;-)