The first step to a successful Azure DevOps migration is to setup your staging VM. I want to completely isolate my migration from my live TFS server.
If you missed the Introduction post, get caught up here.
I highly recommend Microsoft's Azure DevOps Service Migration Guide.
Why a Staging VM?
- I need to delete some code from my TFS repos before importing to Azure DevOps.
- I need to make several changes to the project templates to pass validation. I don't want any of these changes to affect my live TFS server in case I need to rollback.
- I want the live TFS server to become my backup for the code I'm deleting, in case we ever need to access it again.
These requirements make it safest to completely isolate my staging VM from my live VM.
But First...
The very first thing that needs to be done is update your existing live TFS server to use the latest version of Azure DevOps Server. You need to be within the latest two versions to successfully migrate. So, before even starting this process, get your live TFS server up to date.
Setup the New VM
The first step is to setup a VM that will host the migration. The safest path is to not clone the existing VM, but setup a new VM from scratch. This is because cloning the VM will pull across paths pointing at your live TFS VM.
Server
Save yourself some pain later and just install the latest Windows Server version. I originally used the version that my live TFS server was using (2012), but you're going to need some tooling later on that requires later versions of Windows Server. So, just install the latest now, it'll work fine.
You're also going to need a ton of hard drive space. I ended up increasing the size of my server about 4 times during the process as I kept realizing I needed more. Just give it a ton of space to start. I set it to 1 TB for the final import.
SQL Server
Install the exact same version of SQL Server that the live TFS server is using. Install the Management Tools, too. You will need those later.
Install IIS
IIS is needed to access the new TFS install. Install this from Windows Features.
Install Azure DevOps Server
It is critical that you install the exact same Azure DevOps Server version that you are using on your live TFS server. I initially installed 2019, and then had to go back and install 2019.0.1. They have to match exactly.
After installation, close the startup dialog, we're going to use a backup.
Take Full Backup of Live TFS Server
The best way to do this is to use the built-in SQL Backup tooling. I don't actually use this on the live TFS server, but I wanted to use it for this process because it is easiest.
To make it work, just change the TFS databases on the live TFS server to FULL backup temporarily (if they are not already). In Scheduled Backups (on the live TFS server), use Take Full Backup Now.
When the backup is complete, copy it to the C drive of your new staging server.
Be sure to change your live TFS server's backup settings to their initial settings if necessary.
Hosts File (If You're Scared...)
If you are scared of accidentally impacting your live TFS server (like I definitely was), you can be extra safe by blocking access to your live TFS server from the staging migration server.
Open the hosts file in C:\Windows\System32\Drivers\Etc\ and add two lines:
127.0.0.1 <LIVE TFS SERVER NAME>
127.0.0.1 <LIVE TFS SERVER NAME>.<DOMAIN>.local
This is going to point any calls to your live TFS server back to your staging server.
Whew.... feels safer already!
Still Scared? Shutdown the Live TFS Server
If you're still scared, you can also shutdown the live TFS server while you make the big changes, like deleting old code.
My biggest fear is that I'm accidentally logged into the incorrect VM and running commands on the live TFS server. Or I clicked a bookmark in my browser which unknowingly took me to the live TFS server.
For those reasons, it is probably worth shutting down the live TFS server during this process (if possible). If you can't do that, just be very careful when deleting code.
Restore Backups
Back on the staging server, restore the backups on the C: by using the Azure DevOps Management Tool.
In Scheduled Backups, choose Restore Databases. This will handle the SQL restore for you.
Configure Azure DevOps Service
Now, in the Azure DevOps Configuration Center, configure the installation. Use the existing databases, and when asked, choose to Configure As A Clone. This will adjust all the URL's inside the database so they do not point to your live TFS server.
I used the same service users for this TFS install as I used in my live TFS server, however to be extra safe, you could setup new users for this staging server.
Visual Studio 2019
The last step needed is to install Visual Studio 2019. This will be needed later to get access to the TFS commands the SSDT commands.
What's Next?
We now have our staging migration server setup and we're ready to start cleaning up the data to be imported.
In the next step, I'm going to eliminate the data that we don't want to move to our new Azure DevOps Service. This will reduce the size of our import and give us a cleaner final setup.
Oldest comments (0)