We have the staging server setup. We've cleaned out the data that we don't want to import. We're almost ready!
We need to run the Azure DevOps Service validation on our local server to verify that there are no issues before importing. This validation will alert us to any issues that need to be resolved before the actual import.
If you missed the earlier posts, start here.
I highly recommend Microsoft’s Azure DevOps Service Migration Guide.
Start by downloading the Data Migration Tool. This tool contains the Guide, which you should definitely read, and the actual Migration tool.
Copy the .zip for the Data Migration Tool to the staging server and unzip it to the C:.
Open a command prompt and change directory to the unzipped DataMigrationTool folder. This folder contains the Migrator.exe file.
To execute the validation, run Migrator validate /collection:[COLLECTION_NAME] from the command prompt. Make sure you are executing this on your staging server, use localhost:8080 to make sure you are pointed at the right server.
The validation only takes a few minutes to run and it creates a number of log files with the results.
You can view the results of the validation in the command prompt or in the log file stored in the Logs folder of the DataMigrationTool. Open Logs, select the Collection you validated, then click the latest folder (one is made for each migration validation), then open DataMigrationTool.log.
I had a few issues that needed to be resolved, which I'll explain below. You'll probably get different ones which you can lookup in the Migration Troubleshooting Guide. None of the issues I ran into were especially hard, just had to read up on the fix.
This validation error means that you need to rename a work item field. This seems to happen with old databases that have been updated over time. The schema needs to be tweaked to get in sync with the service.
I had about 8 of these to fix, which I was able to do with the witadmin tool inside the Developer Command Prompt.
witadmin changefield /collection:[COLLECTION_NAME] /n:System.IterationId /name:"Iteration Id"
The important thing (which I screwed up at first) was that the /n parameter is the field, and /name is the name that you change it to.
This error means that one of the built-in groups is missing required permissions. It needs to be re-added using the TFSSecurity.exe tool.
Use the instructions at Migration Troubleshooting to resolve this issue.
You may get some validation issues about users, but in my test run I fixed my users after the import by making sure the correct users have access and removing users that didn't belong.
You won't get charged till the 1st of the following month after import, so you will have time to address any user import issues.
If you get a warning that your import is too large and needs to be done by importing to an Azure SQL Database first, your import is about to get a lot harder. I initially had this warning, and it is the reason that I cleaned out more of the data in my import (in our previous step). If you can get under this limit, it will make your life easier. If you can't, you'll need to do a few extra steps on the import which I won't be doing, but I'll provide a link to the guide on how to do it.
We have successfully validated that the Import is ready to go!
Next, we will prepare the actual Migration package.