I'm planning to upgrade TFS from 2013 to 2015. In case something goes wrong during the upgrade installation, I'll rollback and revert every thing to its original state (TFS 2013). I'm performing the upgrade on the same server, which means that if the upgrade is successful, TFS 2015 will override 2013.
Is there an article to follow in case of rollback? Preferably an official article from Microsoft.
Just as jessehouwing's answer above, you can follow the restore procedure, but if your setup includes Sharepoint, Report Server and one or more build servers you may need to revert those too, that would be a very tedious and complex job.
Another way is that you can make a system image to back up you environment first,then restore it in case something goes wrong during the upgrade installation. Please see Back up and restore your PC for details,or use any other backup tools.
You're basically looking at the Restore procedure outlined here:
https://www.visualstudio.com/en-us/docs/setup-admin/tfs/admin/backup/restore-data-same-location
But before you restore you need to uninstall TFS 2015 and reinstall TFS 2013 and its latest update packs.
If your setup includes SharePoint, Report Server and one or more build servers you may need to revert those too. As far as I know there is no definitive rollback documentation. The recommendation is to do a trial upgrade on a second environment, resolve any issues you may find and then perform the final upgrade.
Related
My company is considering upgrading our on prem TFS 2017 update 3 to the latest Azure DevOps Server (notably, the on prem variety).
During discussions about that possibility, one key stakeholder claimed that if you upgrade, all of your build and release pipelines would have to be rebuilt from scratch. We have a healthy number of build and release definitions in TFS 2017.
I have looked for the answer in the Microsoft documentation about what exactly gets upgraded, but unfortunately I can't get the level of granularity which would prove or disprove the above claim. On the surface it would seem like a horrible upgrade story if it were true. But I also understand that designs and architectures change and upgrades aren't always possible.
Could somebody let me know whether the build and release pipelines can survive the upgrade more or less unscathed? Knowing this would be a valuable data point as we work toward a decision.
Thanks in advance!
The vNext build definitions and the release pipeline I would expect would be pretty lift and shift. Depending on the tasks that you have defined, they might no longer be supported or there might be new versions. The UI will let you know that new versions are available.
A lot of the new focus is building out the features for the YAML build definitions. If you want to leverage those, you'd have to do a lot more rework of converting those vNext tasks into YAML. But converting is not really a hard requirement.
You mentioned that you aren't using the XAML build definitions, but if you happened to be using them, I would image that is where a lot of the rework comes in. Having done that in the past, I can say it is a pain if you have to do it.
all of your build and release pipelines would have to be rebuilt from scratch.
I've tested it and it won't lose any data after upgrading. We should use scheduled backups to ensure that we always have backups in place in case something goes wrong.
we can use that new hardware to do a dry run first, and then we will wipe everything clean and use it again for the production upgrade.
For our dry run, the steps for our upgrade will be:
Copy recent database backups to our new SQL instance.
Install TFS 2015 on our new application tier.
Use scheduled backups to restore the database backups.
Run through the upgrade wizard, being sure to use a service account which does not have any permissions in our production environment. See Protecting production in the dry run in pre-production document for more information.
Optionally configure new features which require changes to our existing projects.
The production upgrade steps will be quite similar. There the steps will be:
Take the production server offline using TFSServiceControl's quiesce command. The goal here is to ensure that the backups we use to move to our new hardware are complete and we don't lose any user data.
Take new backups of each database.
Copy the backups to our new SQL instance.
Install TFS 2015 on our new application tier.
Use the scheduled backups wizard to restore the database backups.
Run through the upgrade wizard, using our desired production service account.
Optionally configure new features which require changes to our existing projects.
You can refer to this doc for more details.
As part of a server move, we'll be transferring our TFS and its SQL back-end. Can someone tell me if this is possible, and if so, what order we should be doing the migration vs upgrade? Would it be best to do the upgrade in-place before moving hardware/domain? Are there any particular pitfalls I should be wary of?
Details:
Moving TFS2010 to TFS2018 (potentially via 2013.5)
Moving SQL Server 2008 R2 to 2017
All moves will be done to new hardware on a new domain
Build and work item compatibility is not a concern, as we use TFS only for version control
Direct upgrade to Team Foundation Server 2018 Update 2 is supported from TFS 2012 and newer. If your TFS deployment is on TFS 2010 or earlier, you will need to perform some interim steps before upgrading to TFS 2018 Update 2. Please see the chart below for more information.
Can someone tell me if this is possible, and if so, what order we should be doing the migration vs upgrade?
Yes. You can upgrade from TFS 2010 to TFS 2018. But you have to upgrade to TFS 2012 and newer, then upgrade to TFS 2018. You could refer to the link below:
https://learn.microsoft.com/en-us/vsts/tfs-server/upgrade/tfs-2005-to-2015?view=tfs-2015&viewFallbackFrom=tfs-2018
And, changing the hardware is a restoration-based move, and you should never combine the two move types. First complete the hardware move, and then change the environment: https://learn.microsoft.com/en-us/vsts/tfs-server/admin/move-across-domains?view=tfs-2015v
Would it be best to do the upgrade in-place before moving hardware/domain?
You could do in place upgrade, or move to new hardware. If you're upgrading in place, consider doing a dry run of your upgrade in a pre-production environment, and make sure the system environment is meet.
Are there any particular pitfalls I should be wary of?
Before upgrade, you can read this article first, and be sure you have full backup of your database.
Like many other out there I had the fun task of upgrading or TFS 2008 server to a brand-new TFS 2013 install.
The good news -> this has been done and documented. The bad news -> you have to migrate to TFS 2012 and then Migrate from 2012 to 2013.
All things said it mostly went fairly smooth. I cannot really complain. There is one hitch, however. Or plan was to use an intermediate server (SQLTFS01) for the TFS and SQL Server 2012 install and then most everything onto our destination server for 2013 (SQL008). Then we were to take SQLTFS01 offline and re purpose that machine.
In the end there was a missed step. It seems that our final install of TFS2013 is still pointed to SQLTFS01 for the reporting services components. See here:
Attempts to disable the reporting and analysis services portion of the server are all failing because even in order to disable the tool, it tries to connect to the existing tool.
Question: How can we disable this feature or redirect this stuff? Can we do it though setting files that I am not aware of?
Thanks,
Tom
I would recommend that you "unconfigure" your application tier by running "tfsconfig setup /uninstall:all". This will nit touch any of your data but will reset your app tier to the state before you ran the configuration.
You can then follow the steps in the "move to new hardware" documentation so that you don't miss any of the steps:
http://msdn.microsoft.com/en-us/library/ms404869.aspx
If you start from after "restore databases" step you should be good.
I have been searching the web for a clean solution on how to migrate our 2010 tfs collections to our new tfs 2012 server, but no luck. May someone please assist with the steps or a good blog I could look at to achieve this process. The reason we want to do a MIGRATION and not an upgrade is because we got new hardware and would first like to trial TFS 2012 before we upgrade our live environment. Therefore we would like to import all our collection including the work items and build process templates.
Here is a decent blog post: http://mohamedradwan.wordpress.com/2013/01/05/upgrade-tfs-2010-to-tfs-2012-with-migration-to-a-new-hardware-series/
The basic steps you want to follow are:
Backup all of your 2010 databases.
Restore those databases on the SQL Server on your new hardware.
On your new hardware, install TFS 2012
When it comes time to configure. Select the upgrade option.
It will asks where your databases are. Select the SQL Server that you used in #2.
Press Go.
Note, if you want to test 2012 with the same clients you are using for 2010 then you'll need to "clone" the system otherwise your clients will get confused. To do that, see http://msdn.microsoft.com/en-us/library/vstudio/ee349259.aspx
You can move a collection at a time using the detach option in 2010 and attach it back to 2012 using the attach option there.
See http://msdn.microsoft.com/en-us/library/dd936138(v=vs.100).aspx
I have just installed TFS Server 2010 but during installation I selected SqlExpress as my data tier. Both my TFS application server and database exists on the same box. I also have full enterprise Sql Server edition on the samebox and now want to use the same rather than SqlExpress.
In TFS administration console, I found no way to change my data tier. I haven't created any project as such on TFS so there is no data to migrate. I just want to use my default instance now.
How to go about this ?
FROM https://msdn.microsoft.com/en-us/library/ms404869(v=vs.120).aspx
In order to restore the TFS databases using the restore tool, you must install but not configure TFS on the new data-tier server, and then use the restore function in the Scheduled Backups node.
Install TFS and cancel the setup TFS setup window once it opens. Or in my case I used the Uninstall Application tier option in the TFS Admin Tool. I didn't know you could cancel the application tier install. The wizard kind of forces you into it. Then I had to rename\delete the configuration db and any others that were created in the install.
I had to do this today for a TFS 2018 and found the below article useful. May not fit everyone's scenario but sharing since this SO link came on top of search results.
Run
TfsRestore.exe
in the C:\Program Files\Microsoft Team Foundation Server 14.0\Tools
folder. It has a GUI.
https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2012/jj620932(v=vs.110)
At this early point, you might as well just uninstall and reinstall. That's probably the easiest method.