New Architecture for Migration Tools

[MrHinsh]

Hey folks... Im looking to make a significant update to how the tool works to start moving away from the old Object Model.

The new Model will consist of a "Repository" where any data is stored in json/yaml format. This will be a folder on the system with just files. This new format will also allow us to execute revisions in data order and those remove the need to have the attachment and link writes at the end. It will also enable offline migrations where you export your source, then import to the target from another system.

• TfsMigration - a .net 4 application that uses the TFS Object Model
  • export - uses the TFS Object Model to export the source data to the new filesystem format
  • inventory - outputs an inventory of an environemnt
• DevOpsMigration - a cross-platform .NET 9/10 application that only uses the REST API.
  • export - using REST exports Azure DevOps data to the repository
  • import - uses the REST API to import the repository to Azure DevOps
  • discovery - outputs an inventory of an environemnt

I did not intend to implement TfsImport, although someone can.

Looking for feedback from: @gereon77, @GordonBeeming, @jessehouwing, @MichelZ, @MOlausson, @ovebastiansen , @paulhacker5810. @satano, @tomfrenzel, @wesmacdonald

Questions:

1. What issues do you see?
2. What opportunities?

Results of experimentation:

• exporting a 56k work item environment was 6gb on disk.

[satano]

Hello

Before I found this tool, we had a backup plan to make our own tool to migrate our projects. I did not think about it deeper, but from the beginning I was thinking about something stored on disk. But I was thinking about storing some state of the migration. So in case of some error, I can safely run it again and it will continue from where it stopped. Or even if there was not an error, if something was changed (added) in source, I can run it again and it should run fast, because it knows what was already done.

For examample, quite a slow step is loading of the users, migrating iterations and capacities. If this all was saved in states, running migration again would be fast, because this would be skipped. Of course, there should be a option to forece do it again. I run the migration for my project quite a lot of time, because I am just trying and testing it if everything is correctly migrated. And when it really is, I will do last "production" migration. So some state whould really speed me up.

But as I said, I found this your tool and did not think about it anymore. :) But just one thought, which poped up immediately. I do not know how you plan it, but it would be nice to make some abstractions for everything what you want to do. And then using some stores, which will handle saving and loading things. And one implementation would be files on disk, bus someone can make aj SQL Server implementation for storing everything in database.

And I like the possibility of offline migration. This would speed up of testing the migration, because I can download and prepare everything from source once and run it multiple times to target.

[MrHinsh]

The advantage to files on disk is that its automatically ordered by date :)