Started to upgrade Octopus yesterday and ran into a blocking migration error (see http://help.octopusdeploy.com/discussions/problems/15247-error-migrating-from-16-to-209).
My migration strategy was as the following
- Install OD2.0 on a new machine and import data.
- Install OD2.0 agents side by side with OD1.6 agent on port 10934 on all preprod and prod machines.
- When all agents are connected to OD2.0 correctly, stop using OD1.6 and reimport data to OD2.0.
- Use OD2.0 from now on
Now this leads to a number of questions.
A. Can I just reimport data as many times as I want and existing data will be overwritten (Setting the port number in the migration wizard does not change the port on the registered machines, so it seems that this doesn’t work)?
B. Do I need to delete existing data, prior to a reimport and how?
C. If I cannot reimport, how do I delete existing data, without wiping server thumbprint, master encryption key etc?
D. If i cannot delete existing data, without deleting server configuration, I presume a reinstall of OD2.0 is necessary. Can I set the server certificate/thumbprint and master encryption key manually? I do not want to update 150 machies again and set a new thrusted server thumbprint.
Thanks in advance!
A - yes, the import can be run safely multiple times, but I’d avoid it once you’ve started editing items in 2.0, e.g. the importer matches existing entities by name in many cases, so renaming in 2.0 then re-importing will create duplicates.
B - No.
C - Hopefully no need for this because of A.
D - Also hopefully made unnecessary by A. If you are hitting persistent import issues, please let us know - include as much output from the import script as possible if this is the case. In a worst-case-scenario data can be removed and configuration kept, but this is non-trivial.
I did actually try to customize my dashboard (new feature, so i dought that was the problem) and rename 6-8 steps with illegal characters (front slash and colon), which didn’t get validated as errors during the import. I suspect that might be the problem then.
For future readers with same problems, I ended up uninstalling OD2.0, deleting the database etc, and reinstalling OD2.0 again. For some reason you get the same server thumbprint (thank you!), so I didn’t have to reinstall 150 machines. Before I imported data from OD1.6, I took a backup of the empty database, to I can restore it to the initial state, if this should ever happen again.
Maybe Octopus 2.0 should do a backup of the empty database, when installing, so you always can restore to the initial state. Or have a clear all data functionality, from the Octopus Manager. I have backups of the corrupt database, where I cannot reimport, if you want to drill down into this issue.
Nicholas, thanks for clearing up the import functionality.