I created a new test instance in our octopus server and used the datamigration tools to export from the default instance back into this new test instance. I wanted to re-run the import, but wanted to wipe all that was added by this import. However, using the UI it seems to fail to remove everything from the DB correctly and leaves links to certs tenants and environments all of which no longer existed. I am now having to got through the database manually to clear it all out …
Is this a bug or is there some special order in which I must delete stuff via the UI, so that the DB is left clean.
Our version is currently Octopus v2018.8.9
Cheers,
Andy
Hi Andy,
Thanks for getting in touch! I’ll do my best to answer your question, but I will admit, conversations about data migration are generally complicated.
The import process takes the data from the file system, and merges it in to your target Octopus Server. If you export other data and import that, the import process will do its best to merge that data in to the data currently in the target Octopus Server.
Here is some more information about how the data migrator works: https://octopus.com/docs/administration/data/data-migration
I would also highly recommend upgrading to at least 2018.10 LTS or 2019.3 LTS. We have put a lot of work into the data migrator tooling and upgrading will help you avoid some pain if you intend to use the data migrator heavily.
Hopefully I’ve answered your questions and helped in other ways as well.
I’d be keen to understand: what is the outcome you are trying to achieve using the data migrator?
Thanks!
Mike
Hi Michael,
We have been using Teamcity for a long while here at the company I work at, but have been manually deploying to servers including configs… and choose OD to add the deployment automation part as our pipeline from dev through to live.
We have a large project going on and as part of that project we really started to use Octopus Deploy in anger.
Unfortunately, due to time frames and knowledge levels we learnt as we needed and we only had time to setup one route through our to targets, lets just say “things grew, rather than were built with all requirements in mind i.e. ensuring more than one team and more than one environment was deploy-able to for these other teams teams”
It has been a learning curve for all involved and unfortunately this meant that setting up tenants had to take a back seat due to business delivery windows for the product.
I have been working to get a fully tenanted deployment process setup in another test instance on the same server. However I did not fully appreciate that you could not simply export a project from one instance and re-import it back into the live instance. I sort of assumed that it would be a matter of export json from the interface and importing it back in a bit like you can in TeamCity.
Hence me looking into both octo.exe and DataMigrator to try and achieve this goal.
During testing of this I wanted to simply delete projects from the test instance using the UI, e.g. certs and variable sets etc and then simply re-run the exports over and over again to prove that it all worked as I expected. This was the reason for this post as I found that I had to manually delete “leftovers” from the tables in the DB…
The trouble I am having with the Datamigration tool is that I just want all the tenant project and details of those specific projects but the datamigrator seems to be an all or nothing export import process, I.e users teams etc etc. When i reimport can I simply take the folders that have been produced by the export and just runs those ?
Also on the versions front i would like to upgrade but our purchasing process is … slow … but is in progress…
Thanks for getting back to me ,
Andy
Hi Andy,
Thanks for getting back to me. Sounds like an interesting challenge. Amongst all the pain I hope you are being successful along the way. 
In case it helps I’ll try to answer some questions and fill in some blanks.
Information architecture
Octopus isn’t “project-centric” like some other applications. That’s both an artifact of history, and it’s a bit of a differentiator with pros and cons. It means you can easily share a similar Variable, Certificate, Deployment Target, etc between multiple projects and environments. This comes with the downside of making export/import really difficult. It also means when you delete a project we can delete everything “owned” by the project, but we don’t touch anything which can be shared outside the project. We are considering changes over time where certain resources like Lifecycles, Certificates, etc can be “owned” by a project limiting their scope… but that’s not something on our immediate radar.
Spaces
One of my favourite features of Octopus nowadays is “spaces” which do create fully self-contained “mini Octopuses”. You can create a space for a logical set of Projects, Environments, etc, and delete them all in one hit.
One idea instead of developing your fully tenanted solution in another Octopus Server instance, would be to upgrade Octopus, create a new Space, implement your fully tenanted solution, and move your team over to it.
Partial Export
The data migrator supports a “partial-export” feature where you can select one or more projects and export those, or parts of those. I would highly recommend upgrading if you want to continue using the data migrator so you get all the bug fixes we’ve shipped recently. They may not affect you, but it would be better to be safe than sorry.
Upgrading
If you are planning to renew your license, and it’s something of a certainty, we can probably send you a custom trial license so you can start work in the meantime. This is much easier if you have a quote generated in our purchasing system - this avoids a lot of risk on both sides.
Hope that helps!
Mike