Move license when switching the productive server

[Mamun Ahsan Khan]

I am currently moving our Confluence Server installation to a new machine.

Before I set the new Confluence Server as the active one, I want to make sure, that I did everything right when transferring the data and database.

So this is the current situation:

Old Confluence Server is the active one using Postgres and being licensed.

New Confluence Server has already a set up Postgres database with a dump from the old Postgres DB.

I'm stuck in the installation process whether to choose an evaluation installation or a productive one. I want to choose the productive one without licensing it first, so I can check if the data are displayed correct, then make a delta copy of changes and transfer the license. But I don't want to give the license yet, since this would also deactivate the current running server.

I could also choose an eval installation, then afterwards give the correct JDBC connection string to my postgres database and copy the existing app-data. But I'm not sure if I can then start the new confluence server for testing purpose with the snapshotted live data.

Which way would be better? Or is there another possibility?

I know, that my way doesn't stick to the recommended ways but I'm aware of the potential risks.

[Daniel Eads · Accepted solution]

Hi @Mamun Ahsan Khan ,

Confluence stores its license in a hashed value in confluence.cfg.xml - this is also where the database connection details are stored. The first-time startup wizard (which asks about the installation you're doing) checks for the presence of this file in Confluence's home directory. If it finds an existing confluence.cfg.xml (complete with details on how to find Confluence's database), the wizard won't need to run.

If you've used the same version of Confluence on both instances and are using a dump to copy the database across to a new postgresql server (or even just a new databse on the same postgresql server), a quick method to getting Confluence running on your new Confluence Server would be to copy the confluence.cfg.xml file from your old instance to the new instance.

You would then want to modify the JDBC connection string to point at the new database you imported from your database dump. You'll also want to ensure you've copied over the other contents of Confluence's home directory from the original server, as it includes attachments and plugins.

When you start Confluence up with the copied confluence.cfg.xml (and updated JDBC string), it should skip the new setup wizard and launch right away on your new/restored database.

Let me know if that helps or if you have additional questions!

Cheers,
Daniel | Atlassian Support

[Mamun Ahsan Khan]

Hey Daniel,

thank you for your reply.

It's good to know that the license itself is stored inside the confluence.cfg.xml. This makes it easier to switch the active machine.

But still I don't know, how to check if the copied data and database are working properly. I want to make a test run of the new Server while the old CS keeps running actively.  Then when the test succeeded, I'll do the switch to the new CS making it available for all my colleagues. Therefore I just need a way, to run the new Server for testing purposes but with copied data from the old one.

What would happen, if I let the new Server start already with the XML-file from the old Server and a pointer to the new database? Would this cause heavy issues when two servers are running with the same license key?
Or would it better to stop the old server, then start the new one with modified XML, check if everything works great and then switch back to prepare the productive switch? Would this cause any issues when two different machines one after another connect to Atlassian with the same license while only one is running in this moment?

Best regards,

Mamun

[Daniel Eads]

If you run two instances for a short period, for example to test the new instance while the old production environment is still running, you should not encounter a failure to start due to licensing.

Or would it better to stop the old server, then start the new one with modified XML, check if everything works great and then switch back to prepare the productive switch? 

This is the method I would recommend, as it more closely mirrors the conditions of an actual cutover.

The caveat here is to make sure the database details have definitely been updated to point at the new database. If Confluence cannot establish a lock on the database, it won't start - so in the example of running both environments at the same time, this would actually protect you from accidentally connecting to the existing production database.

Outside from that, the Base URL for the application would be something to think about. Are you going to use the same URL for the new server and simply update your DNS to point at the new stack? Or are you going to use a new URL? You may want to shut down the old infrastructure to check for any places that "redirect" you back to the previous URL, or if you're going to update DNS as part of a "test" cutover, checking that the updates went through correctly. Setting a lower TTL (time to live) for the DNS record can help with the cutover - something like 10 seconds may not be an unreasonable value while you're working through a migration, and then you can increase the TTL value to its previous setting once your migration activities are complete. You'd only be looking at an increased DNS load / slightly slower lookups for the couple days when you're working on a migration. Happy to expand on this point if you need more information!

Let me know if that answers your questions or if I can help more.

Cheers,
Daniel

[Mamun Ahsan Khan]

Hey Daniel,

first of all you really helped me a lot!

I picked the setting where both servers run simultaneously and it all went well. After like 30 minutes and no complaints by Confluence that the license is used twice, I shut the new instance down. Now I'll make a check list which functions need to be controlled if everything works properly and then let some colleagues prove it. This is going to take several hours, maybe even some days but I manage to get everything tested during a week.

Can you specify the "short time" you mentioned where both servers can run at the same time without complaining about the license? And what would happen if this time limit has passed and both are still running?

If there are too many possible harms I'll shut the current server down during the testing period. But if would be great to know which impact it will have when both servers run at the same time.

[Daniel Eads]

Hi @Mamun Ahsan Khan ,

Glad to hear that was of help!

The primary concern is compliance - running two instances with the same license for production use does not meet the terms of the software license agreement. If you have a commercial license - that is, a paid license that's not the 10 user Starter license, you can generate a developer license for use on a non-production environment. Steps for that are listed in Get a Developer License (same steps apply for Jira/Confluence).

If this is a 10 user license, there's no such capability to generate a license for a non-prod environment. For that, you'll need to use your discretion on what's reasonable as a time period and which servers are considered active. The considerations here are legal rather than technical - so while the servers won't shut off, you would just need to be mindful of what an auditor might find out of compliance with the software terms.

[Mamun Ahsan Khan]

It would help me already if I could have any additional background information, how Confluence handles the license usage.

Since this posting reveals, that the JIRA license key is stored inside the used database, I'm not sure whether Confluence works the same way.

In that case I would shut down the old Confluence Server, then link the new database with migrated data to the new Confluence Server and start this afterwards. Then it should start up already with the license and work properly. But I can still shut it down again and start the old Confluence without any harm.

Maybe this is not intended to use Confluence as this could be used to abuse the license but I don't see any other way to test the new server with our data before making the productive switch.