Thanks for getting in touch with Octopus!
As there was a lot of information in your original post, I have tried to answer your questions under some headings below. As with any type of migration, trying to reduce the number of moving parts will help here, so please disregard any information you consider irrelevant to whatever plan you settle on .
I’ve also written up some advice on some of your future aspirations covering an upgrade, High Availability, and Okta.
Moving Octopus Server and Database
If you just want to move the Octopus Server and database (without any upgrade), then we have a guide on our website on https://octopus.com/docs/administration/managing-infrastructure/moving-your-octopus/move-the-database-and-server
Proposed Migration Plan
Your proposed solution looks very good. I would only add that you would also need to copy the following directories from your original server to the new server (each of these folders are located in C:\Octopus in standard installations).
- Task Logs
- This folder only needs to be moved if using the built-in package repository. External feed details are stored in the database, and they will connect automatically.
The above is taken from our migration process guide here.
The copy step should be done prior to this step:
Start up the newly created Octopus instance and do some local testing (at this point all tentacles will still be pointing to the old instance.)
CNAME Record and Polling tentacles
Just a specific mention on this as you noted this is of major concern to you.
Assuming the CNAME record you will move was used with your polling tentacles when they were first registered e.g.
https://CNAME-RECORD-TO-SERVER-ADDRESS:10943 then this looks spot on.
By changing the CNAME record, this should mean the change of hosting Server should be transparent to the polling tentacles. I’d also recommend reducing the TTL on the CNAME record as well.
Does the above process seem like it will be the best approach for our lift and shift?
A: Yes, I think this approach looks good, please refer to the Proposed Migration Plan for additional comments on your plan .
Is it sufficient to move the database or do we have to update settings in the database?
A: Yes, you shouldn’t need to update the settings in the database unless you plan to change the directories for Artifacts, Packages, and Logs
Are there any setting on Octopus server that will need to be updated? Such as our new instances we set the paths for the files (log / artifacts and packages)
A: As above. Please see here if you do plan to alter the standard installation folders.
Is there anything we can do to dry-run this?
A: Yes, you can indeed dry-run a large majority of your proposed plan. My suggestion would be to do a dry-run up to the point of switching the CNAME record.
One thing that might catch you out is that the deployment targets and any project triggers may also attempt to fire when you start the new version up.
To counter this, you can disable all deployment targets and any project triggers.
- You can run an API script to disable all project triggers on your test migrated instance. You can find a sample script here - https://github.com/OctopusDeploy/OctopusDeploy-Api/blob/master/REST/PowerShell/Projects/DisableAllProjectTriggers.ps1
- You can run an API script to disable all machines on your test migrated instance, to be absolutely sure that nothing will deploy. Again a sample can be found here - https://github.com/OctopusDeploy/OctopusDeploy-Api/blob/master/REST/PowerShell/Targets/EnableOrDisableAMachine.ps1. You can then enable them as you run through testing.
Please note: that scripts are given with no warranty. I have not run or verified them. You will need to double-check scripts before running them.
Can we mitigate the tentacles from being updated by locking their versions? Or is this overkill as we are doing a like for like on the versions? 3.15.7 -> 3.15.7
A: I wouldn’t lock their versions personally as you are doing a like-for-like version migration. You can lock them if you want to be sure though.
Is there anything we need to look out for when changing the Operating System from Windows 2012 r2 to Windows 2019. I’m guessing 3.15.7 has no known issues running on Win 2019?
A: Nothing specific that I am aware of. However, I haven’t tested a migration of this specific version, so you should verify this yourself. Generally speaking, I would check things such as the version of Powershell, and any other tooling that may be installed by default on Windows Server 2019 - such as the .NET Framework version.
Our other Octopus installs (4 separate setups) are all using listening tentacles (or workers) and we have seen previously that when we update the CNAME they happily connect to the new instance, but we have limited knowledge on polling tentacles, will they act the same way?
A: See the section on CNAME above. I have not tested this myself, but I believe it should be transparent to the polling tentacles providing the TTL is low, and a health-check is performed after start-up of your new instance.
You should be able to test the CNAME change by simulating a change on one of your polling tentacles (or install one locally, providing it can access the new instance) using a HOSTS file entry.
We have a page that discusses upgrading in-depth, and you can read this on https://octopus.com/docs/administration/upgrading/guide. The TL;DR; version of this is to ensure you have something you can roll back to in case of a failure in your upgrade process.
I’d recommend testing out the upgrade, to ensure that there is no interruption to your deployments.
The 2 main options you have are:
- An in-place upgrade; where you would perform a database backup and file system backup. (If your Octopus Server is hosted on a Virtual Machine, you could also look to perform a snapshot too). This option is easier but slightly riskier as the upgrade is in-place.
- A new server and database (Lift and shift). This would involve cloning the database and the machine that Octopus Server is running on and then test the upgrade in isolation. This option is less risky but there is also a lot more work involved with this approach.
In most cases, an in-place upgrade is fine and this is what I would recommend - particularly when you are moving from versions between “modern” versions, which are considered from v3.x up - as is the case for you.
At the time of writing, the latest LTS version is 2020.1.5.
Please note: the minimum requirements for Octopus Server have been raised from version 2020.1 and above. The TL;DR; is that to install 2020.1 we recommend
- Windows Server 2016 or higher
- SQL Server 2017
You can see the announcement on the reasons for this change on https://octopus.com/blog/raising-minimum-requirements-for-octopus-server
Based on your New position - 2020.1 would be able to be installed as long a you choose to also use SQL Server 2017 or higher.
I’d also recommend checking for any breaking changes from 3.15.7 to 2020.1.5, to compare the release notes between versions and view breaking changes, please see https://octopus.com/downloads/compare?from=3.15.7&to=2020.1.5
Move to HA Octopus
We have a page that discusses configuring Octopus High Availability, and you can read this on https://octopus.com/docs/administration/high-availability/configuring-octopus-for-high-availability
I’d pay particular attention to a couple of sections of this guide:
The polling tentacle set-up is of importance when going to a HA configuration. Listening Tentacles require no special configuration for High Availability. Polling Tentacles, however, poll a server at regular intervals to check if there are any tasks waiting for the Tentacle to perform. In a High Availability scenario Polling Tentacles must poll all of the Octopus Servers in your configuration.
Note: There are ways to automate this that don’t involve restarting the tentacle. You can run a script using the Script console, or using a worker on behalf of all the deployment targets to configure the additional nodes. Please see here for the command line you would need.
We have documentation covering Okta authentication on https://octopus.com/docs/administration/authentication/okta-authentication
I hope that helps, and best of luck with your migration!