Me and my colleague have inherited an Octopus Deploy setup and we are both new to the system.
The issue we have now is that we have to migrate this OD application to a new server (luckily for us the database is stored on another server), and we are a little bit oblivious to how we should do it.
I found this guide on ODs site, but that seems almost a little too easy. And it doesn’t say anything about the intranet site that has to be setup on the new system and redirected from the old.
We also have a TeamCity integration that has to be migrated with the server aswell.
Is there anything we should be extra careful about when migrating to a new machine?
Thanks for getting in touch!
Migrating the Octopus instance is easier than you’d expect. The majority of the important parts are stored within the database, the instance itself is essentially just the web frontend and file storage.
As your database isn’t being moved, this guide is more specific but the general steps are the same.
The part that the guide glosses over slightly is creating the new instance on the new machine. When creating the new instance you will be required to specify what user the service runs as (this user will need permissions on the database. It would be easiest to check what the current service runs under and use the same account), the file storage location and the default port for the web portal.
Once the instance is created you will likely need to configure additional web bindings, such as a secure HTTPS binding.
This is done via the Octopus Manager app as detailed here.
The only other item that comes to mind is to ensure connectivity on the new machine. Any tentacles will need access on either port 10933 or 10943 depending on the communication mode being used for them.
The last bit of advice is to be absolutely certain that you save the Master Key from the current instance and take a backup of the database. You shouldn’t need the database backup for the migration, but I would have it just in case anything goes wrong.
The Master Key is only stored on the instance machine, it isn’t available in the database and if it is lost it would require all sensitive values within the database to be reset, which would be a major impact on any Octopus users. So, storing that key someplace external (e.g. a key vault or password manager) is the best option.
thank you for your quick reply!
I will check out your links and start to prepare our migration. As far as I know we only have listening tentacles (10933) which makes the migration easier aswell if I understood the documentation correctly?
Of course, we have stored the key on another location. But if it goes crazy, can you just start up the old machine again or is that one fried once you started your migration?
That’s right, listening tentacles should just be looking for the instance DNS, so, no real issues there.
Turning the old server on if things go wrong should also be fine.
We’ve started the migration but found a little problem on the way.
The other instance of octopus deploy doesn’t recognize our license number.
Do you know where we can find it on the old server and verify that we have the correct one documented?
You should be able to find the license XML in Configuration > License on the old instance.
You’ll need to copy the full XML into the new instance license prompt.
We found it! Thank you. =)
Now for the next question, is there a way to find this setting? (The person before us wasn’t much for documenting things apparently. We have tried a couple of different settings but it wont take it.
On the old instance if you navigate to the Octopus home folder (default c:\Octopus) there will be a Octopus.Server config file there. That file will have the SQL connection string that may help you find the right details for that part.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.