I went to do an upgrade of TFS2015 to TFS2018.2.
In past tests and experiences, these upgrades take some time against the collections if they are on the larger side. I first started a POC with TFS2015 to TFS2017.3 and that took 24 hours total to do the upgrade and it was successfully completed. As I was doing the POC TFS2018.2 RTM, so I went with the same POC but this time I went from TFS2015 to TFS2018.2, that upgrade only took about an hour or so, which seems really odd.
It looks like it completed without error but the amount of time it took to upgrade the collections seemed really off, compared to any other upgrade I have done in the past. How long is the upgrade process expected to take?
The length of time to upgrade the collections depends on the amount of changes made to the database, and which tables changes were made to, and the size of the team project collection databases.
I recently performed an upgrade against a 500 GB collection from 2015 to 2018 and the entire upgrade process took 20 minutes. It's fast.
Previous versions to 2015 were slow because TFS 2015 introduced significant database schema changes. Nothing after that has required such a major schema change.
Related
I know someone answered this question here
but there is only one answer and no feedback from the author. I'd like to have more sources before starting my upgrade.
So, we're planning on upgrading TFS 2010 to TFS 2018 but we need to keep working while doing so.
Is it possible to have on going modifications while upgrading to TFS 2018 and commit them when the upgrade is done ?
Thanks in advance
It depends on what you mean by "working". If you're talking about source control, then yes, the answer to the other question is accurate. If you're talking about work item changes, builds, etc, then the answer is "no".
When doing upgrades on TFS instances considered critical for business, the best process to use is this:
Do a test upgrade first, leaving the existing instance online.
Fix any problems that you discover that occur post-migration and, if necessary, write scripts to quickly apply the fixes
Re-test the upgrade process, including applying your fixes
Do the final upgrade over a weekend or overnight, outside of normal business hours
I am using TFS 2015 on-premise for all our builds and releases. Recently some of our releases have been taking far longer than normal to complete. A release that normally took 20 minutes has been taking several hours.
We release to both on-premise web servers and Azure, and we get the problem with both. It doesn't happen with every release, which makes diagnosing the problem very difficult. We've re-started the TFS server but it still keeps happening.
The on-premise releases are just a Windows Machine File Copy task and Azure releases are an Azure Web App Deployment task. All pretty straight forward. The problem only started recently (over a week or so ago). There have been no updates or changes to the TFS server, so can't fathom why this has started happening.
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.
We are migrating 60 Thousand workitems from TFS 2010 environment to 2012 environment using the TFS Integration tool. In the test environment is took very less time as less traffic was there , but in production environment it is taking more than 2 weeks as calculated by the current speed it is going in.
Is there anything we can do to speed up the migration ?
How does the tool works to migrate these workitems ?
You can add new query in TFS Integration Tool to reduce the amount of work items to be migrated at one time.
I had started the upgrade from 2012 to TFS 2015 3 days before 2 of the collections have completed and one of the collection out of 3 is running from Day one.Its size is about 2.5 TB.Having said that , i had performed same upgrade months back and it had finished successfully in 52 hours.Can any one help on the reason why it is taking a longer time now ?
Look at the screen shot for reference:
Upgrade Window in progress
There is a log named TFS_TFSUpgrade_Date_Time with the type TFS Upgrade in Team Foundation Server Administration Console→ Logs.
You can compare the logs between twice upgrade to check which step had taken a longer time.