I found migration guide which uses command line. However, since there is no TFS server, I can't use the TFS migration tool.
A few workaround ideas I have ...
Can I export data from SQL Server directly and then import that into VSTS?
Can I install TFS (fresh new install on new VM) and connect to the existing SQL Server somehow?
I have no idea if above idea would work. If not, what possible options do I have?
Just reinstall the TFS application tier. When the wizard opens, you can choose "Application Tier Only" which will walk you through connecting it to the databases.
Make sure you reinstall the same version of TFS you were using before (including Update) -- if you were using TFS 2015 Update 3 before, reinstall TFS 2015 Update 3. Don't try to install Update 4 or Update 2.
Related
We have a TFS 2013 instance that requires upgrading. I plan to use Azure DevOps 2019 on prem. I'd like to have the two environments running at the same time so I can verify. What I'd like to do is:
Do full install of Azure DevOps server, creating new DBs on a new SQL server. I do NOT want to upgrade our existing TFS at this point.
Copy the data from the original TFS SQL instance to the new SQL instance, performing an upgrade along the way.
Test and verify all data successfully migrated to 2019
Schedule a blackout window and repeat the import process once again
Can anybody advise if this is do-able or refer me to a guide?
Tks
Easier than I thought. Just needed to run the pre-production upgrade wizard.
We have created a VM clone of our TFS server (but haven't turned on networking yet for the clone).
We have created a test SQL server that we plan on using for the test upgrade.
I'm not sure what we should do first (after populating the tfs databases on the test SQL server).
Since our test TFS server is a VM clone, TFS is installed and configured already. The Cloned TFS server is pointing to our production SQL server. Are the following steps correct:
Turn on networking for the Cloned TFS server
Remote into the Cloned TFS server
Run command TFSServiceControl quiesce
Run the command TFSConfig PrepareClone
Run the command TFSConfig ChangeServer ID
Run the command TFSConfig RemapDBS
Update the TFS URLS in the admin console
Edit Reporting to point to the new test Reporting instance
Update all service accounts
Are the steps correct? I am not sure which order to carry out the steps out after the TFS databases have been put on the test SQL server. Any help would be greatly appreciated.
I would suggest doing the following:
Unconfigure your test server. I assume you don't want to upgrade your production server yet, you just want to test the upgrade, correct? If that's the case run 'TfsConfig.exe setup /Uninstall:All' to unconfigure the new server.
(if you haven't done it already) Backup all TFS databases from production server. You'll need all DBs with the names starting with 'Tfs_' including Tfs_Configuration, Tfs_Warehouse and all collection databases.
Restore TFS backups from production on VM or some other test SQL server (using SQL server management studio)
Run tfsconfig changeserverid command (on the new server) to change the TFS server id. It's required because you want to have both TFS instances live for some time. If you don't do it, VS clients will think that it's the same server (even though the name is different) and this can cause some issues.
Run tfsconfig remapdbs command (on the new server) which will fix the old Tfs_Configuration database. This is only required because you are moving TFS to a different machine (with a different name)
Now you can start TFS management console and perform the actual upgrade which is pretty straightforward. Upgrade wizard will ask you for the new service account names and new test reporting instance location.
I plan on replacing my existing app tier (TFS 2010) when upgrading to TFS 2013. I'll quiesce the services and rename the old machine from MYTFS to MYTFS_OLD. The new app tier will have a fresh, un-configured installation of TFS 2013 and will be renamed from MYTFS_NEW to MYTFS.
My question is, will it be necessary to run the ChangeServerID or RemapDB commands if the new app tier is named the same as the old one?
If I understand your scenario correctly you will end up with:
A new server that's completely clean
The 'old' database server that contains all the TFS databases.
If that's the case, you should install TFS and select 'Upgrade'. You then point your TFS Application Tier to your database server and let TFS upgrade your databases.
You cannot have both version running on the same set of databases.
Study the ALM Ranger's Upgrade guide before doing anything.
I don't think you need to run remapdbs or changeserverid commands:
you typically need remapdbs when the server name changes which is not the case
you should use changeserverid if you plan to clone a TFS server meaning that you have restored TFS databases to a different machine and set up another TFS instance on that machine without killing the original server. Again it's not the case from what you have described here.
2 days ago I did the following test upgrade from TFS 2005 to 2010 then to 2012 (I am not configuring Reporting or Sharepoint)
Backed up the 6 TFs 2005 databases
Restored them on the Sql 2008 server used by TFS 2010
Ran TFSconfig setup uninstall:ALL on the TFS 2010 application server (as I had a test site setup)
Opened the TFS 2010 admin window and did an upgrade
Detached my TFS2010 collection and did an import process to TFS2012
Yesterday, I wanted to try the process again to make sure that I had all the steps down.
So I did some initial cleanup
Deleted all the databases on the TFS 2010 Sql server
Detached the test collection on TFS 2012 and then delete the associated database
and then I restarted the steps but it gets stuck at step #4
Backed up the 6 TFs 2005 databases
Restored them on the Sql 2008 server used by TFS 2010
Ran TFSconfig setup uninstall:ALL on the TFS 2010 application server
Opened the TFS 2010 admin window and did an upgrade
The error I get on step #4 is
TF254024: No database for Team Foundation Serer that can be upgraded were found on the following instance... Verify that you specified the correct name of the server and the instance.
I've double checked the name of the server & instance.
Made sure that the account that is running the upgrade has full permissions.
I'm not sure what else to do. My searching hasn't proved that fruitful.
I figured out the issue.
When I was testing out the deploy the first time, we were trying to do a migration instead of an upgrade. We had added 2 extended properties to the master table from the TFSIntegration database (based on another error).
I removed both those extended properties and I was able to start the upgrade.
edit 1-
I tried the process again (restore database and try to do the upgrade). The extented properties were back again.
so running this script fixed the process.
USE TfsIntegration;
GO
EXEC sp_dropextendedproperty
#name = N'TFS_DATABASE_CATEGORIES';
GO
EXEC sp_dropextendedproperty
#name = N'TFS_INSTANCE';
GO
I have installed TFS 2010 on a new server (vmware running windows server 2008 r2) and restored from backup my old TFS 2005 Database onto the new server. The installation seems to have succeeded - I can create a NEW TFS 2010 team project and I can do checkin/checkout for it.
I made a mistake, however, with the TFS 2010 configuration manager - I ran the advanced configration wizard and NOT the upgrade wizard.
Now I don't see my old TFS 2005 team project and the upgrade wizard is now disabled.
In order to fix my mistake I tried this:
TFSServiceControl quiesce
tfsconfig import /sqlInstance:MyServer\DBinstanceName /collectionName:MyImported /confirmed
This is the output of this commands:
TF255152: Service is not running: TFSJobAgent
The upgrade of the project collection MyImported has been queued.
Waiting on the upgrade operation to complete.
...and now I am waiting for too much time for this operation to complete (my version control DB is 15 GB).
How can I import my old TFS 2005 team project to the new TFS 2010 server?
Here you go it supports inplace upgrades...
If you have to do a migration and it is currently jacked up then I would simply start from scratch. You'll spend far less time doing this than trying to fix the issues.
If you choose an install (advance configuration wizard in your case) instead of an upgrade, what happens is that new configuration and default collection databases are created for you, and your restored 2005 databases are not touched.
The safest way to deal with this issue is, like Chris suggested, to start from scratch. You wouldn't need to restore your 2005 databases again though, all you need to do is to uninstall TFS, make sure the new Tfs_Configuration and Tfs_DefaultCollection databases got deleted, and reinstall TFS and configure again with the Upgrade wizard. Installing TFS 2010 should be fast.