Data migration errors between different OD versions

I am facing issue migrating data from 3.2.13 server to 3.11.4. Below is the error log for my migrate preview. We have no plans for upgrading source (old) server. 3.11.4 is our test sever and I got this error testing out migration. Our original plan is to migrate all the data from 3.2.13 server to 3.4.14.

Also, does versions have to be same between source and destination to export the data? Is there any way to force this step or skip this step(if its not important) for migration.

2017-04-19 10:53:26.0443 1 ERROR ===============================================================================
2017-04-19 10:53:26.2593 1 FATAL Could not find type ‘Octopus.Core.Model.NuGet.Feed’ in assembly ‘Octopus.Core, Version=3.11.4.0, Culture=neutral, PublicKeyToken=null’.
Newtonsoft.Json.JsonSerializationException
at Newtonsoft.Json.Serialization.DefaultSerializationBinder.GetTypeFromTypeNameKey(TypeNameKey typeNameKey)
at Newtonsoft.Json.Utilities.ThreadSafeStore2.AddValue(TKey key) at Newtonsoft.Json.Utilities.ThreadSafeStore2.Get(TKey key)
at Octopus.Migrator.TypeConversionBinder.BindToType(String assemblyName, String typeName) in TypeConversionBinder.cs:line 15
at Octopus.Migrator.ImportProcess.ImportedDocument…ctor(JObject instance, JsonSerializer serializer, IMasterKeyEncryption sourceMasterKeyEncryption) in ImportedDocument.cs:line 80
at Octopus.Migrator.ImportProcess.SourceProviders.ExportedFilesSourceProvider.ReadDocuments in ExportedFilesSourceProvider.cs:line 53
at Octopus.Migrator.ImportProcess.ImportController.IdentifySourceDocuments(ImportContext context) in ImportController.cs:line 385
at Octopus.Migrator.ImportProcess.ImportController.ExecuteWithTimer(ImportContext ctx, String name, Action1 work) in ImportController.cs:line 160 at Octopus.Migrator.ImportProcess.ImportController.ImportDocuments(IImportedDocumentSource backup) in ImportController.cs:line 97 at Octopus.Migrator.ImportProcess.ImportController.Import(IImportedDocumentSource backup) in ImportController.cs:line 80 at Octopus.Migrator.Commands.ImportFilesCommand.Start() in ImportFilesCommand.cs:line 98 at Octopus.Shared.Startup.AbstractCommand.Octopus.Shared.Startup.ICommand.Start(String[] commandLineArguments, ICommandRuntime commandRuntime, OptionSet commonOptions, String displayName, String version, String informationalVersion, String[] environmentInformation, String instanceName) in AbstractCommand.cs:line 78 at Octopus.Shared.Startup.OctopusProgram.Start(ICommandRuntime commandRuntime) in OctopusProgram.cs:line 235 at Octopus.Shared.Startup.ConsoleHost.Run(Action1 start, Action shutdown) in ConsoleHost.cs:line 77
at Octopus.Shared.Startup.OctopusProgram.Run() in OctopusProgram.cs:line 106

OctopusMigrator.2017-04-19_10_45_11.7368.txt (3 MB)

Hi!

Thanks for getting in touch! The data migration tool was built for two primary use cases. The first is to migrate data from Octopus 2.6.5 -> Octopus 3.x where 3.x is the exact version you want to upgrade into.

The second is to synchronise multiple Octopus Server clusters, or provide a way to source control your configuration. We test this kind of scenario for export/import on the exact same version - data which is exported by 3.2.13 can be imported by 3.2.13 (for example).

We haven’t specifically built knowledge into the migrator tool about how to transform data from any export from a source version of Octopus into a target version of Octopus. It works in some scenarios by sheer chance. We don’t actively support crossing versions, and recommend against doing so, but we also don’t prevent it just in case it gets you out of a jam.

In your scenario I would recommend upgrading your source Octopus Server to 3.11.4 and then the export/import should work as expected.

Is there something preventing you from upgrading your source Octopus Server?

Also, is this a one-time migration after which you will decommission your source Octopus Server?

Either way I would strongly recommend taking database backups of both your source and target servers just in case the migration has any unintended side-effects.

Hope that helps!
Mike

Thanks Michael. Good info on that. The one above cross version migration was for my test. The real planned migration is from on 3.2.13 server to 3.4.14. You think it would work there by any chance or would you recommend source version to upgrade to 3.4.14 and export?

To answer your above questions.
Is there something preventing you from upgrading your source Octopus Server?
Not aware. Need to check with other teams.

Also, is this a one-time migration after which you will decommission your source Octopus Server?
I would guess a Yes or use it for non production services.

I was able to successful migrating all the data from 3.2.13 to 3.4.14 using the migrator.exe. All the data looks good except for the tentacles. I understand the thumbprints change for tentacles and hence the connection fails. But is there a way to connect to all the tentacles from server side? without going to all the tentacles

Hi!

Thanks for keeping in touch! Our supported approach for data migration is to:

  1. Upgrade the source Octopus instance, which will run all of the database schema changes to get the data into the correct shape for the target Octopus instance.
  2. Migrate the data from the source instance which merges it into the target instance.

This will be the path with the least possible problems. :slight_smile:

Regarding reconnecting your Tentacles, as long as they are still successfully connected to your source Octopus Server instance, you can use the Script Console to run a custom script on each of the Tentacles forcing them to trust the target Octopus Server.

You should create a script something like this which will stop the Tentacle from trusting the source Octopus Server, and switch it over to trust the target Octopus Server:

Tentacle.exe service --stop --console
Tentacle.exe configure --reset-trust --console
Tentacle.exe configure --trust "YOUR_TARGET_OCTOPUS_THUMBPRINT" --console
Tentacle.exe service --start --console

See our documentation on automating Tentacle installation for Listening or Polling Tentacles.

BEWARE: You should test your script on a single Tentacle before rolling it through your fleet - this is a one-way operation. :slight_smile:

Hope that helps!
Mike