I am doing an upgrade from TFS 2015 to TFS 2018.
I moved a collection from my TFS 2015 to my TFS 2018 as refered in the documentation:
https://learn.microsoft.com/en-us/tfs/server/admin/move-project-collection
The process was successfully done according with TFS 2018 Administration Console after I attached it.
After this I compared both collections (from TFS 2015 and 2018).
I could watch that the migration was not entirely done. In TFS 2018 I was missing this:
In my original Collection I had 3 projects. THe projects are still in there, however Project P1 used to have 6 members (4 users and 2 groups). Now it only has 4 users. The groups are missing. Any idea why?
In Project P1, In TFS 2015 I had a Visual Studio definition build. Now, In TFS 2018 I could see that the "Publish Build Artifact" is now deprecated.
In this build options I noticed in my "Multipiers" field I have this message "This setting is required". In TFS 2015 I could leave this field empty and I wouldn't get this message.
At the moment I haven't noticed any more changes, but I am worried about this.
I have more collection to migrate from TFS 2015 to TFS 2018-
How should I address this migrate process?
Related
At work, I've been put into the role of TFS administrator, as the real TFS admin is leaving our organization in two weeks. We're currently using TFS 2015. I'm trying to upgrade us to TFS 2018, hopefully before the current admin leaves.
To that end, I've been reading various resources on TFS migration from TFS 2015 to TFS 2018. One resource I came across is this one Migration from TFS 2015 to 2018. This document spoke about integration between TFS 2018 and SharePoint. I had thought that integration died, after TFS 2015. Specifically, up to TFS 2015, TFS had what they called "TFS Project rooms". Sort of like a simple bulletin board type system. But Microsoft decided to break that connection, so I was lead to believe, after TFS 2015.
So, I'm wondering, since the linked to PDF speaks of integration between TFS 2018 and SharePoint, what is that about? Especially if TFS team rooms have gone away?
According to this doc about TFS 2018 and SharePoint integration:
TFS 2018 and later versions no longer support integration with SharePoint.
The SharePoint integration supports the TFS 2017 and earlier versions. In TFS 2017 and earlier versions, in addition to the team room function, this integration also has other functions.
For more detailed information about sharepoint integration , you could refer this Blog.
Since you are upgrading the TFS 2015 to TFS 2018, if you have configured the SharePoint integration in TFS 2015, you need to disable the SharePoint integration after upgrade.
In addition, in TFS 2018, we start to use Microsoft teams or slack for monitoring and communication.
Hope this helps.
Think this MS-Post might give you the answers: The future of TFS/Sharpoint Integration
We have TFS 2013 SP 4 (our existing version) and TFS 2017 (which is under testing for we are upgrading the TFS version).
My question is : Is it possible to work and test on both the TFS at the same time with the same workspace?
Business users are able to configure the new TFS 2017 and work there. However, when they are switching back to TFS 2013 (since we have not gone live with TFS 2017), it throws an 'Identity does not exist error'.
Has anyone tried it?
Is it even possible to test this way? Or shall we have one TFS version at a time for one workspace even for testing?
Thank you.
Anant
When upgraded TFS 2013 to TFS 2017(using TFS 2013 backup) on a new Server, the two servers have the same TFS GUID, which will confuse your Visual Studio clients.
You should avoid having two TFS up & running with the same set of GUIDs. And this is usually avoided by shutting down the old TFS server after the upgrade has finished and has been tested & verified.
We have to upgrade TFS version from 2012 to 2017. The problem we are facing is we have some team projects in TFS 2017 lower environment and some team projects are in 2012 production instance. We want to migrate 2012 team projects and 2017 team projects to a new TFS 2017 production instance under one team project collection. We need some help in defining the upgrade/migration strategy keeping this scenario in consideration. Please let us know if someone can lend help.
It supports to move collections from TFS 2012 to TFS 2017 directly follow the move collection document. You don't need to upgrade your TFS 2012 to TFS 2017 first. It does the upgrading When it attaches to the new TFS instance, just follow theses steps:
Detach the collection
Back up the collection database
Move the collection database
Attach the collection
Configure Features for team projects(option)
Note: The step5 is done when you move TFS 2012 collection. If you move TFS 2017 collection to your new TFS 2017. This step doesn't need to do.
And you want these 2 collection to merge to one collection totally. This is not support currently. There are two many conflicts: changeset numbers, work item IDs, builds,etc. And it also doesn't support to move team project from one collection to another. Here is a user voice about move team projects between collections which has many votes already:
We still plan to evaluate picking this work up and possibly getting it into the following next major release. We’ll provide an update once a decision has been reached.
I'd suggest that you do the migration from TFS2012 to TFS2017 just as described by Microsoft here and after your new TFS2017 is up and running, move the Team Project Collections from your current TFS2017 to the new one which is described here
We currently have a TFS 2012 Server which is being replaced by a 2015 server, the aim is to gradually migrate our code from one to the other.
When we do this we would like to maintain the checkin history, labels etc, Looking at similar questions the answer seemed to be to use the integration toolkit, however it looks like it (and its successor the integration platform) do not support TFS 2015.
We are using TFVC rather than git, if that makes a difference.
I don't have much knowledge about the integration toolkit, but I would actually suggest to do the upgrade one Team Project Collection at a time, but moving them separately to a new server with TFS 2015 installed. This way you will keep all history, label etc.
We have done this way back when upgrading from TFS 2010 to TFS 2013. Only obstacle that we had was a collection around 500 GB in size so it took around 16 hours for the upgrade to finish.
The following answer specifies the steps needed to move a collection to another server:
Copy TFS 2012 collection to another server with TFS 2015 Installed
We have used this Migration tool for our Client.
It’s possible to migrate TFS 2012 data to TFS 2015 with all information intact without any system downtime. The premium version of OpsHub Visual Studio Migration Utility (OVSMU) supports migration of projects with TFVC repository from one instance to another. It supports the 2010, 2012, 2013, and 2015 versions of TFS and all versions of Visual Studio Online, including the 2017 version. Along with basic data, you can migrate all workitems with history, comments, attachments, relationships, and source control with changesets, history, labels, comments, etc. You can checkout the details here: https://www.opshub.com/products/opshub-visual-studio-migration-utility/
First day trying new VS Community 2015 RC Version 14.0.22823.1 D14REL.
Our TFS server is still TFS 2010; I'm wondering if that's the source of the problem.
Other Team Explorer sections are working fine -- Work Items, Source Control Explorer, Pending Changes. I even did a merge and checkin successfully.
But the Builds section shows this:
I'm not even sure where to look for an error log.
VS.NET 2012, still installed on the machine, shows the Builds section correctly.
As support for TFS 2010 ends before VS 2015 releases don't expect the support to be awesome. If you don't have SP1 then your are already out of support. None of the editions of Visual Studio 2015 (and 2013) officially support TFS 2010 RTM.
I would recommend that you upgrade to TFS 2013, or TFS 2015 at your earliest opportunity. If you need support for that then get a consultant to help who has a good relationship with MSFT.
If your ops team is inside of keeping software up to that's and with the applications support model then you should seriously consider moving to VSO so that you don't have to worry about It any more.
Reinstalling VS 2015 after my Windows 10 debacle, I found that suddenly everything was working including builds! With the server still on TFS 2010. Apparently my problem was that I had the VS 2015 Community Release Candidate, not the final release.