Data migration errors between different OD versions.

mamidalascm's Avatar


19 Apr, 2017 06:20 PM

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=, Culture=neutral, PublicKeyToken=null'.
   at Newtonsoft.Json.Serialization.DefaultSerializationBinder.GetTypeFromTypeNameKey(TypeNameKey typeNameKey)
   at Newtonsoft.Json.Utilities.ThreadSafeStore`2.AddValue(TKey key)
   at Newtonsoft.Json.Utilities.ThreadSafeStore`2.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, Action`1 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(Action`1 start, Action shutdown) in ConsoleHost.cs:line 77
   at Octopus.Shared.Startup.OctopusProgram.Run() in OctopusProgram.cs:line 106

  1. Support Staff 1 Posted by Michael Noonan on 20 Apr, 2017 12:30 AM

    Michael Noonan's Avatar


    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!

  2. 2 Posted by mamidalascm on 20 Apr, 2017 01:19 PM

    mamidalascm's Avatar

    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?

  3. 3 Posted by mamidalascm on 20 Apr, 2017 01:28 PM

    mamidalascm's Avatar

    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.

  4. 4 Posted by mamidalascm on 21 Apr, 2017 03:25 PM

    mamidalascm's Avatar

    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

  5. Support Staff 5 Posted by Michael Noonan on 24 Apr, 2017 12:41 AM

    Michael Noonan's Avatar


    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. :)

    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. :)

    Hope that helps!

  6. Paul Stovell closed this discussion on 28 Jul, 2017 04:37 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac