What would you recommend or what is the official recommendation of Microsoft regarding migration path after pre-production (test) upgrade?
is it to do an In-Place Upgrade? or is it to do a database migration to a new hardware? Need this information for one of my customers.
The second question is, let's say I choose the second approach and make a production upgrade moving the databases to new hard, do I have a rollback if something goes wrong? or the old environment becomes unusable once I make a production upgrade (remember I am using new hard/VMs)
Many thanks
Actually it's completely based on your requirements. If you want to use the old hardware then you can do In-Place upgrade, if your want to migrate to new hardware then just do the database migration.
In-Place upgrade:
Please note that you cannot simply rollback for In-Place upgrade if something goes wrong. So backup the databases first.
Expect the best, prepare for the worst.
While we put a lot of effort into ensuring that TFS upgrades are
highly reliable, it always makes sense to prepare for the case where
something goes wrong. The single most important step you can take here
is to ensure you have a complete and consistent set of database
backups.
If you're upgrading in place (not moving to new hardware), consider
doing a dry run of your upgrade in a pre-production
environment.
Source here: Upgrade TFS.
You can reference this article to do the upgrade:
In-place upgrade to TFS 2017 RTW (Release To Web) with Reporting and SharePoint
Migrate to new hardware:
Migration will be more flexible and safe, the old environment will still available, it will not be affected if the migration failed. So in my opinion if you have new hardware, then it should be better to do the migration.
Please see Move or Clone Team Foundation Server from one hardware to another for details.
Please note that whether it is in-place or migration, it must match the Requirements and compatibility first for each TFS version. And never forget to Backup the databases for both of them.
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.
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
We have TFS server to be moved to a new Hardware please suggest the steps involved and the best approach.
The DB instance will also change will just Backing up and Restoring the Collection DBs be fine? and attaching these collections to the New TFS setup?
Thanks & Regards
Just as DaveShaw suggested in the comment, there are official tutorials in MSDN, you could simply follow the suggestion there. The steps are very clear and detail
Restore data to a different server than the current one for TFS
If you also want to do the version upgrade something you could pay attention such as :
Pre-production upgrade is just a dry run of your upgrade in a production environment.
Usually we use this to test your upgrade. This process test upgrades the databases. You can use this to simultaneously test your TFS on another hardware while continue to use your existing older TFS up.
Once you are ready for upgrade, restore the databases again and just use the Production Upgrade scenario during the server configuration wizard.
Besides, suggest you directly move the changes in the production environment later, a tutorial for In-place upgrade to for your reference.
I assumed this would be easy, but I'm not finding anything on it...
I have a project in TFS 2010, which needs to be moved to a new TFS 2015 server. Apparently the project cannot simply be moved normally because it's using a different project template which is not compatible and causes errors when trying to migrate (so I'm told - I don't have any more details on this).
I'm looking for a way to bring over the changesets, keeping history, to the new server. I assumed there was some kind of "dump" where you could export the TFS changesets, then import them into the new server into an empty project - but I'm not finding that option.
TFS Integration is deprecated and apparently doesn't work for TFS2015, with no alternative listed.
I'm open to other creative options like temporarily exporting to a different version control system - for example, I've looked at SVNBridge, but I can't even get that working, let alone figure out if it would help here.
Is there a way to migrate all changesets for a given project and keep history, without migrating the entire project?
There is no default way to migrate changesets in TFS, you would need 3rd party tool, like OpsHub (some features are not free), to migrate the most commonly requested data. Check: http://www.opshub.com/products/opshub-visual-studio-migration-utility/
Or you may consider doing a upgrade from TFS 2010 to TFS 2015, which is a full data transfer. To understand factors that affect your upgrade's compexity, check the requirements and review the upgrade process.
Learn if a dry run makes sense for you, and weigh the benefits and the costs to perform a pre-production upgrade.
When you're ready to upgrade, minimize downtime with the TfsPreUpgrade tool - especially for very large TFS collection databases (> 1 TB). Follow these steps for how to upgrade TFS.
What does OpsHub say the migrations speeds are per changeset with The
VSO Migration Utility?
Does the commercial OpsHub Integration Manager tool improve the
performance?
One of our projects has 72,000 changesets and labels and our first attempt was still running after 3 weeks and had only got less than half way.
How does the VSO Migration Utility manage with changing TFS 2010
codebase while migrating?
Developers are changing code while the migration is happening is this
advised?
Does ongoing file changes slow the migration? Does it matter?
If the migration takes weeks then it's the only option.
If the tool does not manage file changes while the migration is
taking place how do we update VSO afterwards with the new changes?
For our utility, your dev team can continue using your on-premises TFS without any hassle. The utility will automatically detect those changes and migrate them in sequence. (This goes for both workitem and source control)
The only side effect is that in the tool the count at the end of the migration will be shown as ACTUAL MIGRATED/COUNT DETECTED AT START OF MIGRATION.
And where the former is greater than the latter. eg. 2000/1500. This however is only user interface limited and does not effect your actual migration.
And no, on-going migration is not hindered in terms of speed by changes in your TFS instance. I am assuming you are using the v1.5.0.00 of the utility.
We are working on our next release which focuses greatly on performance improvements. We'll update you once the release is out, it should help you achieve migration in much shorter time span.