Migrating to Azure DevOps can be a one-time, complex project that often requires specialized expertise. In this video, I discuss why it’s typically better to bring in experienced professionals for your migration rather than trying to build skills in-house. Migration is often a deep, technical process, especially when handling data inconsistencies or navigating older TFS setups with unique quirks.
With years of experience in DevOps and as the creator of Microsoft’s recommended migration tools, I’ve seen firsthand how expertise can make or break a smooth migration. For organizations planning multiple migrations, I also offer training and support for in-house teams, ensuring they’re equipped to handle ongoing transitions.
Video Chapters:
00:00 - Why In-House Skills Aren’t Enough for DevOps Migration
00:28 - Complexity of Database Migration and Compliance
00:57 - Handling Data Inconsistencies and Legacy Issues
02:07 - Benefits of Expert-Led Migration Tools
03:07 - Options: Hiring Professionals vs. Training In-House Teams
04:18 - Conclusion: Why Expertise Matters in DevOps Migration
👉 Watch the video to learn why bringing in specialized help is key to a successful Azure DevOps migration. Like the video, subscribe to our channel, and stay tuned for more in-depth DevOps insights! Visit
https://nkdagility.com/capabilities/azure-devops-migration-services/
if you need #azuredevops #devopsmigration #devopsconsultant #devopstraining
Watch on Youtube
One of the biggest issues with migrating Azure DevOps up to the cloud is probably that you’re only going to do it once. Because you’re only going to do it once, you’re unlikely to have the skills already in existence in-house to be able to do that migration. It probably doesn’t make sense to build and maintain those skills in-house because it’s something you’re probably only going to do once.
For Microsoft’s database migration, depending on the size of your database, it can get quite complicated. It doesn’t quite hit complex, but when you start running a lot of the validation tools against it to make sure that your environment is compliant for moving up to Azure DevOps, is when you get a lot of wacky stuff. There are rabbit holes you need to go into to understand a lot of that stuff because there are things that perhaps could have happened to your system. For example, in the past, somebody had a particular version installed, and Microsoft made a mess up. They released a patch, and between the install and the patch, somebody made the change that the patch is supposed to fix, but it didn’t quite fix the actual data. Then you’re left with data in a little bit of an inconsistent format.
What you normally need to do is run some commands against the system, and understanding those commands and what they’re actually doing can be quite a deep rabbit hole to get into. Ultimately, we’ve done hundreds of migrations. I’ve been working with Azure Ops since it was Visual Studio Team System, and it launched back in 2005 or 2006. I’ve been working with it for a long time, and I built the tools that Microsoft recommends to do the peace more peace bu migration. Like, I want to move one team, I want to merge projects, I want to split projects—those types of migrations require even deeper skills necessary to be able to run that tool.
It’s really, really flexible, and when you have things that are really, really flexible, that increases the complexity and configurability of that thing. You need somebody to spend a lot of time figuring that out. We have that knowledge and expertise because we built the tool. If you’re going to do one migration or a few migrations over a small period of time, you’re probably better off just hiring somebody to do that work. If you’re going to do a whole bunch of migrations over a long period of time, I do also work with customers where we train people within the organisation to use the tools, and then we help them run the tools on a continuous basis.
We help with support because you always run into crazy things that are specific to you as a customer. Those data shapes that I mentioned, perhaps in the midst of your TFS environment, your environment—the database was originally controlled under the control of the developers because it’s a developer tool. Maybe operations didn’t really own it, and the developers decided to install TFS 2013 Beta 1, which was supported by Microsoft but can cause lots of weird data things. Then it’s on track; it’s been handed over to operations, but there are some weird idiosyncrasies in there.
So, bringing in expertise for those types of things, whether it’s for training the people that you have that you want to do long-term lots of different migrations, or if you just want somebody to take it off your hands and do it for you, that’s ultimately what we’re here for. You don’t need the expertise in-house.
