Reputation: 707
I am upgrading TFS 2012 to TFS 2015 in a new hardware with a new configuration. My strategy is to copy the DB and upgrade them and after sometime switch over to the new TFS 2015.
There will be some time between the actual switch over of the TFS from 2012 to 2015, (in my case it will be days). This approach is taken because we cannot have production downtime of the TFS.
Now the time (days) taken, there will be lot of new data inserted in the old TFS 2012 database. How will I migrate the new additional data to the new TFS 2015?
I am having the question because TFS 2015 versus the TFS 2012 there are table changes, this will be taken care by TFS upgrade. But if I want to insert TFS 2012 data to TFS 2015 will there be any issues? or is there a better approach to the upgrade?
Upvotes: 1
Views: 867
Reputation: 114461
An alternative not mentioned yet is to consider an detach/attach migration. This would allow you to upgrade your installation one project collection at a time and would reduce the downtime of the whole server to a per collection level. If your server has multiple collections it may be worth the extra effort. The overall migration will be much longer, but you'll have the opportunity to plan each collection individually to happen at the least disruptive moment.
For the duration of the migration you may be able to up the specs of the TFS and SQL Server, especially if you run virtual. I've added 8 extra cores and 16gb of memory in the past just to speed up the process. Switching to fast network storage or taking the opportunity to upgrade the machine to SSD's is an opportune moment.
Also ensure that your SQL Server has been configured for massive i/o. The migrations tend to move a lot of data around. Having your SQL logs on a separate drive and your tempdb split across different files equal to the number of course cores can make a huge difference.
warning: there have been known issues with detach operations causing loss of security groups. TFS 2015 will detect these cases and will warn you when you attempt to attach the collection. The correct process is to have a server backup from just before the detach operation and restore if the detach fails.
note: while there are tools that can sync data between servers, they tend to only cover partial data migrations. Many don't support work item tags, none support transfer if kanban column data, builds, changes to security settings etc. All migration tools have one thing in common and that is that they lose the timestamp of changes. All of these tools are written on top of the TFS client object model, so the notion you can easily migrate additional data later is not true. If it were that easy these migration tools would have broader coverage and fewer bugs.
Upvotes: 0
Reputation: 23434
You should do a test migration to help you understand how long the upgrade will take.
Once you have this information you will need to take your TFS offline to do the upgrade. This is usually a quick process that can be done in the evening or weekend.
The idea that you can't take any server offline for regular maintenance is a faulty one and is unachievable.
You can't insert data into the database ss this will break tfs.
Syncing data after the fact will prove very difficult and time consuming.
Upvotes: 1