Moving some projects to a new separate Octopus Instance

(Robert Sandru) #1

as part of a company spinoff activities I need to separate some projects and associated dependencies from an existing Octopus instance to a fresh new one.

I’ve tried to use the migrator tool to export one of the projects (there are 96 in total) and import it into a blank Octopus instance but the transaction is rolling back at the end due to an error.

Can you give me some hints as to where I need to look, the log file tells me this:

2019-07-02 12:00:42.5569 15624 1 ERROR Error importing Project ‘01.CHIL’ (Projects-209):
2019-07-02 12:00:42.5569 15624 1 ERROR Missing dependency Projects-209-2018073104385264

I am not sure what ‘Projects-209-2018073104385264’ is as it doesn’t look like a proper project key.

Here are the commands I used to export and to import:

.\Octopus.Migrator.exe partial-export --clean --directory=c:\export --project=‘01.CHIL’ --password=abc123

.\Octopus.Migrator.exe import --instance=xxxxx --directory=c:\export --password=abc123

Both Octopus Deploy instances run on the same VM so are the same version. MS SQL database also running on the same server.

Any hints for further diagnosis would be highly appreciated.

Best regards,

(Kenneth Bates) #3

Hi Robert,

Thanks for getting in touch! I’m sorry to hear you’re hitting this unexpected issue on importing this project. The Missing dependency Projects-209-2018073104385264 seems to imply that the project you’ve exported contains a Deploy a Release step to trigger a deployment of a different project (`Projects-209) - is that assumption correct?

If that’s correct, it looks like you’re probably hitting a current known bug reported here. The workaround to this issue is to additionally export the dependent project (that’s deployed via the Deploy a Release step in your 01.CHIL project) in your partial-export command. You can specify this project in the same command by adding another –project=VALUE option.

If this isn’t applicable to your scenario, could you let me know which Octopus version you’re using to help me reproduce this behavior?

I look forward to hearing back and getting to the bottom of this one!

Best regards,

(Robert Sandru) #4

Hi Kenneth,
sorry for missing the obvious information: Octopus Deploy 2018.10.4 LTS.

I have searched for a “Deploy a Release” step in the project’s process and couldn’t find one so it may or not be the bug you mentioned… can I send you the 01.CHIL project process .json file, maybe I’m missing something obvious as I’m not familiar at all with the project in question.

I also tried to find out if Projects-209-2018073104385264 actually exists but it doesn’t (I simply tried the /api URL to fetch it:

“ErrorMessage”: “The resource ‘Projects-209-2018073104385264’ was not found.”

whereas for Project-209 (that’s our ‘01.CHIL’ project), I obtain:

“Id”: “Projects-209”,
“VariableSetId”: “variableset-Projects-209”,
“DeploymentProcessId”: “deploymentprocess-Projects-209”,
“ClonedFromProjectId”: null,
“DiscreteChannelRelease”: false,
“IncludedLibraryVariableSetIds”: [],
“DefaultToSkipIfAlreadyInstalled”: false,
“TenantedDeploymentMode”: “Untenanted”,
“DefaultGuidedFailureMode”: “EnvironmentDefault”,
“VersioningStrategy”: {
“Template”: “#{Octopus.Version.LastMajor}.#{Octopus.Version.LastMinor}.#{Octopus.Version.NextPatch}”,
“DonorPackage”: null,
“DonorPackageStepId”: null
“ReleaseCreationStrategy”: {
“ChannelId”: null,
“ReleaseCreationPackage”: null,
“ReleaseCreationPackageStepId”: null
“Templates”: [],
“AutoDeployReleaseOverrides”: [],
“Name”: “01.CHIL”,
“Slug”: “01-chil”,
“Description”: “CHIL cloud services”,
“IsDisabled”: false,
“ProjectGroupId”: “ProjectGroups-543”,
“LifecycleId”: “Lifecycles-221”,
“AutoCreateRelease”: false,
“ProjectConnectivityPolicy”: {
“SkipMachineBehavior”: “None”,
“TargetRoles”: [],
“AllowDeploymentsToNoTargets”: false
“Links”: {
“Self”: “/api/projects/Projects-209”,
“Releases”: “/api/projects/Projects-209/releases{/version}{?skip,take,searchByVersion}”,
“Channels”: “/api/projects/Projects-209/channels{?skip,take,partialName}”,
“Triggers”: “/api/projects/Projects-209/triggers{?skip,take,partialName,triggerActionType}”,
“ScheduledTriggers”: “/api/projects/Projects-209/scheduledtriggers{?skip,take,partialName}”,
“OrderChannels”: “/api/projects/Projects-209/channels/order”,
“Variables”: “/api/variables/variableset-Projects-209”,
“Progression”: “/api/progression/Projects-209{?aggregate}”,
“DeploymentProcess”: “/api/deploymentprocesses/deploymentprocess-Projects-209”,
“Web”: “/app#/projects/Projects-209”,
“Logo”: “/api/projects/Projects-209/logo?cb=Projects-209-2018073104385264”


(Kenneth Bates) #5

Hi Robert,

Thanks for following up and providing that additional information! Projects-209-2018073104385264 is is your project logo file name (which takes the form of Projects-ID-Date). It looks like the import is failing as the project isn’t able to find the logo file. These files are stored in your Artifacts folder (C:\Octopus in standard installations), so I suspect you’d just need to copy that file to the destination instance’s artifacts folder.

Let me know how you go or if there’s anything else I can assist with. :slight_smile:

Best regards,


(Robert Sandru) #6

Hi Kenneth,
you got it right! I’m experimenting this on a copy of the production instance and I indeed missed copying those folders to my test instance… I can see that the export operation has copied those logos in the export folder now and that the import operation doesn’t fail anymore.

I do have another import warning message I need to investigate but I’m not sure if you prefer me opening a separate request for support or if you’re ok to piggyback on this same thread.


(Kenneth Bates) #7

Hi Robert,

That’s great to hear, thanks for letting me know that fixed the import error. :slight_smile:

You can certainly piggyback on this same thread! I’ll be happy to look into this new warning message you’re hitting.

I look forward to hearing back.

Best regards,


(Robert Sandru) #8

Hi Kenneth,
so I now tried exporting / importing the whole group of projects (95 of them) and hitting a different error.

I have attached the log file for your reference. EDIT: I can’t attach for some reason, even though the log file is only 2MB…
ImporterLogSnippet.txt (5.6 KB)


(Kenneth Bates) #9

Hi Robert,

Thanks for keeping in touch! The new error you’re hitting as reported in your logs is indicating that both the source and destination projects have channels with the same name. In this case, I think all you’d need to do is add the --overwrite option to your import command which will force any name-matched documents to be overwritten. (Also to be safe, we always recommend taking a backup of your db in case you need to roll back).

I hope this helps get you going! Let me know if there’s anything at all I can assist with. :slight_smile:

Best regards,

(Robert Sandru) #10

Hi Kenneth,
I actually did try with the --overwrite option but it just hits a different problem later in the import process. See attachment log file snippet.

ImporterLogSnippet-2.txt (6.3 KB)

Should I attempt to export / import each project independently? It’s a bit tedious as there are 95 of them but I could script it…


(Robert Sandru) #11

Hi Kenneth,
do you need me to provide any additional information to diagnose this? I tried a few times the export/import procedure and I’m ending up with the same error.

Kind regards,