Every few weeks, I talk to a potential customer about migrating their on-premise Azure DevOps Server or Team Foundation Server to the cloud. There’s almost always a certain level of confusion because — well — it’s really confusing. There’s a lot of things to think about and it’s not always clear what the best way is to actually get their stuff to the cloud.
Here are some thoughts on how to do it.
There’s a data migration tool from Azure DevOps that will help you to do a high-fidelity data migration into the cloud. But this isn’t always the best choice for customers. It’s a lot of work and often the return on investment (ROI) just isn’t there.
The first big important questions are around how you use Team Foundation Server or Azure DevOps Server right now.
- Are you developing software for regulated industries like finance, medical, accounting, or auditing?
- Do you use AZDO/TFS for project management? Are your product backlogs, project plans, and bugs in Azure DevOps?
- Do you use AZDO/TFS for QA testing? Are all your QA test cases in AZDO/TFS? Do you care about your historical QA test results (for example for compliance and auditing purposes)?
- What version control system do you use? Git or Team Foundation Version Control (TFVC)?
- If you use TFVC, what’s your branching structure look like? Is it complicated? Do you want to keep that structure? Is it essential for compliance and auditing?
- Do you have lots of complex automated builds and releases in AZDO/TFS? Are they using Classic Pipelines (JSON-based) or are they using the modern YAML-based pipelines?
If you’re in a regulated industry, you’re almost certainly going to want to do a full import to the Azure DevOps cloud. If you are a heavy user of the project management tools and/or the QA testing tools and you want to keep your data, you’ll probably want to do a full import.
If you use Team Foundation Version Control (TFVC) and you want to keep using it and keep your history, then you’ll need to do a full migration. If you use TFVC and want to move to Git you have options. If you’re already using Git, you have options.
It starts getting harder to decide the further you move down the question list. If you use a lot of automated builds and releases but you don’t care about the historical data, you might just want to opt for a simpler move.
Identity & Azure Active Directory Questions
If you have an existing TFS or Azure DevOps Server that you’re using on-premise, you almost certainly are using Active Directory for identity. Your users log in to their (for example) Windows workstation using their username and password and from there they can access TFS/AZDO without having to retype their passwords.
When you move to the cloud, you’ll want to be able to do this same flow so that your users only have to log in one time and always use their corporate identity credentials. This means that you’ll need to setup a synchronization between your existing on-premise Active Directory and your cloud-based Azure Activity Directory tenant.
If you’re using Office 365 for your email and/or for SharePoint, this has already been done for you. If you’re still using an on-prem Exchange Server or an on-prem SharePoint server, this synchronization might not have been established yet.
If it’s not done, you’ll need (well, want) to do it so that your users can use their existing usernames and passwords with the Azure DevOps Services cloud.
Version Control Migration Options
If you’re like lots of companies, you really never used Team Foundation Server or Azure DevOps Server for much more than just source control. Put another way, you don’t use the project planning tools, you don’t use the QA Testing tools, and you don’t use the automated build/release tools.
If that sounds like you, then you have some simpler options. In fact, you can sort of think of this move to the cloud as an opportunity to clean out all the old junk that might be hanging around.
Migration Option #1: Dump Your History and Go
This option is super easy. You could probably call this the “brute force” option. It’s sometimes known as a “tip migration”. A tip migration takes the latest version of your code (aka. “the tip”) and just copies it into a new version control repository in the Azure DevOps Service cloud. This is great if you don’t care about your version control history. It’s also nice if you’re going to use TFVC in the cloud. It’s a super-easy, pragmatic approach…but it’s 0% elegant.
On someone’s workstation, get latest from your current version of the code. Get latest from the target version control repository in the cloud. The target will be empty because it’s totally new. Then just do a file copy of everything you care about into your target folder. Check it in or commit it and then push it up to the cloud.
That’s it. You’re done. To be honest, you can probably do this in an afternoon.
Migration Option #2: Move Your Git Repositories to the Cloud
First off, it’s worth pointing out that Git is Git is Git. Git at GitHub is the same as Git in Bitbucket is the same as Git in Azure DevOps is the same as Git anywhere. It’s all the same.
Git repositories (“repos”) are extremely portable. And because of how Git is constructed, all the history is neatly contained inside that repo. So if you want to move your Git repository to another hosting provider, it’s the matter of just a handful of command-line calls.
Just set up a new “remote” for your git repository and then push to that remote. Done.
Migration Option #3: Convert your TFVC to Git
So what do you do if you’re using Team Foundation Version Control (TFVC)? TFVC doesn’t move between servers easily at all. If you’re like a lot of companies, you’re thinking about converting your TFVC source control over to Git. If that’s something that you want to do, now’s a great time to do it.
Azure DevOps Server has a truly fantastic and extremely well-hidden feature that lets you convert your TFVC repository to Git. If you use this feature you can convert up to 6 months of version control history over to Git. Once you’ve done this, you can move that Git repo up to the cloud just like I described in Option #2.
Now, as with just about everything, there are disclaimers. The history conversion isn’t super beautiful and the timestamps for the commit times can seem a little wacky. But overall, this is a great way to move your TFVC repository to the cloud.
What If You Can’t Do Any of These Easy Options?
Ok. So those are some of the easy options. What if that doesn’t work for you? Well, that’s where you need to start considering using the Azure DevOps Data Migration tools.
I’ll cover that process in an upcoming blog post.
For now, I hope this helped you out to better understand what the migration options are. If you’ve got thoughts or questions feel free to drop me a line.
— Need help with your Azure DevOps data migration? We can help. Drop us a line at firstname.lastname@example.org