Can we do a phased migration from Octopus Deploy (trial license) to a fully licensed production quality server?

We initially tested Octopus Deploy on a local server (not production quality), using the trial license (5 projects, 10 target servers). Everything went well, we’ve bought in to this technology. We purchased a full license and this is now on a new “production quality” server. I am working to migrate these projects from the local server to the new server.

FYI: for us, Production Quality Server means one that has sufficient redundant infrastructure support to run 24x7, along with typically higher CPU/RAM/Disk resources and with frequent backups to protect data. The local “development” server simply doesn’t meet this level.

The complication is that three of the five projects are actively being worked and pushing packages several times a day. The other two are quite right now and thus ideal to migrate as we will be able to test/exercise once on the new server. We wish to keep using the existing server for this deployment cycle for those active projects.

The backup from the original server is dependent on the master key. When we import to the new server using this master key, I am reading that we can continue to use this master key and thus the tentacles will continue to use the same thumbprint.
I know the new server already has its own “master key”.

  • How do we tell this new server to use the old master key?
  • Is that something that happens during the import?

We use listening tentacles.

  • Will these tentacles get confused if the old servers is still in use while starting the new server?

“Phased migration” meaning we migrate 2/5 now, and when the current development cycle concludes (another month or so) we migrate the remaining 3/5.

Hi Andrew,

Thanks for getting in touch! Unfortunately I cannot recommend the process that you would like to perform. The major problem being that the Tentacles will see the instances as the same, and it can cause issues with deployments when Tentacles send deployment requests back to the incorrect Octopus Server. Imports do take care of both master keys and thumbprint/certificates.

Being you have not been running the instance for very long the migration process should not be a long process. You may need to consider downtime or selecting a time your projects aren’t being worked on to perform this.

Sorry it isn’t better news! Let me know if I can help with a migration plan.