Question posted in 
The company where I work has decided to take a big step and upgrade the internal versioning system, and I am partly responsible for it.
Currently we have an old server that will be replaced soon that has TFS 2010 installed, we have about 100 GB of codebase and we would like to migrate to Azure DevOps Server 2022.
I am aware of the migration steps that need to be done (2010 to 2013, 2013 to 2015, and 2015 to 2022) but I was wondering both about the time it takes to do this and any advice on how to do it without breaking everything, maybe from someone who has been through this before.
Thanks in advance to anyone who can give me some advice.
I have already consulted the following links:
2
Answers
Migrating from TFS 2010 to Azure DevOps Server 2022 is indeed a significant task, i totally understand your concerns, however it’s hard to say the time as it can vary greatly depending on the size of your codebase, the speed of your hardware, number of servers deployed, and other factors.
But with careful planning and execution, it can be done smoothly.
Firstly please check the Upgrade tips and advice listed on the official upgrade doc:
a. Do check the system requirements.
b. Make sure you have a complete and consistent set of database backups available.
c. Do the upgrade and Configure new features.
In addition, before your upgrade, it’s recommended to delete not-needed projects, artifacts, pipelines…etc, shrink the database can speed up your upgrade(backup your database before the operation).
This indeed is a big responsibility but with good planning you can manage the upgrade with minimizing the risks to none.
Firstly i would suggest you create a clone to your environment (Same resources, clone of your production DB’s, etc.) and then go ahead with the first upgrade. (2010 -> 2013)
During then you should take notes and your times that will eventually represent your company’s down time.
Then, if possible have another clean environment which you will clone the upgraded TFS to, then perform another upgrade (2013 -> 2015). Also remember to take your times. If not possible you can go with in-place upgrade, but if anything happens during this upgrade you’ll need to start the process from the very beginning (upgrading from 2010).
And same process from 2015 -> 2022.
During the process you should note anything that didn’t go as expected and the fixes that needed to be done, so on production day you should be 100% aware of anything that can happen and prepared with the fix.
I would suggest when you go with production upgrade to separate the upgrades and not do them all in once, to mitigate the risks of not finding potential issues or missing data between upgrades.