This migration utility helps customers to migrate the most commonly requested data from an on-premises Team Foundation Server to their Visual Studio Online account. It is designed for basic migration scenarios to migrate history of version control changesets, work items etc.
We have done some testing with the tool, and while it seems that it generally works, we have some showstopper issues.
1) For some reason, it is extremely slow - OpsHub is looking into the issue, but we currently estimate a 9-day migration time for 5 Team Projects with a decent amount of changesets and work items. 2) More of an issue, though, is that the dates of Work Item Closed Dates, etc. as well as the Changeset dates are not migrated. This means that we cannot run realistic reports after migration or effectively track code changes.
I realize that issue #2 is not really in the hands of DevOps, but it would be nice to see a fully supported migration path from Microsoft where all available data is migrated. Otherwise, at least in our case, we cannot get started with VSO. There will simply be too large of an overhead after migration to do this.
Ryan, On #1, The migration speed is dependent on number of revisions, connectivity speed, the speed of end point and size of changesets and attachments (as they need to be transferred over the network to VSO).
On #2, The current VSO (and TFS) API doesn't allow us to set those attributes on a write. Hence the limitation.
Works well if you have a vanilla install of TFS and a brand new VSO instance with admin rights for both.
If you need any advanced customizations beyond that (e.g., being able to cloak incoming folders, re-base your import under a sub-folder, select only a subset of changesets to import, etc) I don't think you will be able to. It only includes the most basic settings: an instance of TFS to import from, an instance of VSO to export to.
It also has the tendency to fail easily. I had a very old TFS instance that had been upgraded from 2008 to 2010 and then again 2012. I'm not sure if it failed due to some corruption in TFS (it worked fine for us through VS), or if it was due to some historic branching issues. It also seems to need a lot of permissions.
Overall, it's the best product available, and you can't beat the price (free), but it can be problematic and require a little tweaking to get just right.
The utility is not designed to migrate from customized templates on TFS side. If you have customized templates on TFS side, the utility will give an error. If you are getting any other error please post it in Q&A section and we will help you in resolving it.
Worked very smoothly and completely migrated ~15 realtively simple projects and ~1,300 changesets. After configuring online security and mapping logins, the process couldn't have been much smoother. The only issue I've noticed so far is that check in timestamps for revisions will be set to the time of migration check-in; however, the comments have the original check-in user and original timestamp. Overall, this is an excellent utility - highly recommended for moving collections from TFS to Visual Studio Online!
Even though my VSO project is using 'Team Foundation Version Control', the tool is saying that is is using 'Git Version Control' when trying to migrate version control data. I could have sworn this worked a few weeks ago.
Error details: '[project-name]' is using 'Git Version Control' in your Visual Studio Online. Version Control migration for Git repository is not supported. So either choose only to migrate your work item data or create a new 'Team Foundation Version Control' based project with the same name in your Visual Studio Online and try again.
This is usually encountered when the User through which the Migration Utility is connecting to VSO does not have enough permission to access that project (or is not a Team Member for that project). Microsoft TFS API does not directly provide the information regarding the Project's Source Control Type and this is done through a different detection algorithm that OpsHub implements. Wherein, not having access to the project through Source Control API too is regarded as the project having GIT Version Control.
Could you please verify if the user has permissions as required in the per-requisite document for the utility?
We have been working on migrating from TFS2010 to VSO for the last week.
First we ran out of space on the SSD used; there where 27 GB in TFS_Temp?! as a workaround we have symlinked the directory to a 1 TB drive; seems to work.
Saturday we had cleaned up some reference problems with 3 of our earliest workitems and started again.
It went through the workitems in about 6 hours and started on the code.
Around 2:30 the code migration ran into problems;
OH-SCM-009: Error occurred while sync. No files checked in.
From what I can see it is changeset 1105… it was a big merge to Main; as we had moved to Silverlight 5 on the branch.
But it is not clear to me what the problem is…?!
FYI I have sent you a mail with logfiles attached and additional information.
My Dev Team is attempting to migrate a TFS 2013 Project to Visual Studio Online.We start the utility, go through set up steps, map users, and then start the migration, and it looks like it just hangs with no updates (visually atleast) once the migration begins. We let it run over night, yet no change. Is this by design, any help would be appreciated.
Also looking at the logs we get this common error, which points to a security context being lost or something in that manner, but we were able to setup the entire migration, so connection with the tfs server with the creds was successful:
Failed to login to Team Foundation Server : 'Server Url' with user : null. Server Error : ; nested exception is:
java.net.ConnectException: Connection refused: connect. You may have given wrong credentials or credentials are not valid now.
We've been struggling with template mismatch errors. We have tried to migrate unmodified existing Agile & CMMI projects, without success.
We tried creating a new Agile (2013.3) project on premise & VSO, created one work item and tried to migrate that, but still receive template mismatch errors (it seems for every work item type).
Trying to import a work item definition (Bug) from VSO to on premise, we get the error "The field Microsoft.VSTS.TCM.ReproSteps cannot be renamed from 'ReproSteps' to 'Repro Steps'."
Any suggestions as to what we can do to move forward?
Can you send us screen shot of the errors in UI (may need multiple screenshots)
Also from where you have downloaded template?
Can you send us log located at <OpsHub Installation Directory>/logs
Please email all the information to firstname.lastname@example.org
Sandeep - we had the same issues, but we did not download any template. We used the default Scrum/Agile templates that come with TFS, and also couldn't get any of our work items to work in the migration. It said there was a template mismatch error. The only other factor I can think of is that our local TFS was originally a 2010 install, and upgraded to 2013.
Are you using Scrum template (from TFS2010). If so, support for it was missed in the current version. A new version of the utility which will be out in early feb will have this support.
If you are not using scrum template, please send us screen shots of the errors along with template versions to email@example.com
I am also having issues with migrating a from Scrum template (from TFS2010). Your earlier reply mentions an early Feb upcoming release that should resolve this issue. Will this be available soon?
My team is starting to migrate our projects over, but it looks like our shelvesets are not transferring over. Are they not covered by this utility, or is there something special we need to do to move them?
I have two different TFS systems (2010 and 2012) with different projects. Can I selectively pick and choose which projects to move to VSO? I.e. when I've migrated one TFS instance, can I then run the tool again and move (different) projects from the other on-premise TFS into the same VSO I just migrated other stuff in?
It would also allow me to migrate projects one-by-one when the time is right for each... (I have about 31 projects scattered across those two TFS instances).
This is a 2 part question:
1) Is it possible to configure OpsHub to skip a specific folder during the migration ($/Proj/BuildProcessTemplate specifically)?
2) I was also hoping to migrate everything into an $/Proj/ARCHIVE folder. Is this possible? So on TFS it was $/Proj and on VSO it would be in $/Proj/ARCHIVE
I don't see any obvious settings, but perhaps there's a config file or something that I can edit?
I'm getting this error after 5 migration progress... My project has 2568 changesets and everything was running fine till I got this error: Session Factory for OpsHub DB session is null erevery time I click on the View Progress option. Finally if I go to the Migrations list I'm not able to find it.
One of the possible reason for this error can be that the database may be locked by some other process, for unlocking the database please follow below steps
- Close the migration utility.
- Take backup of the folder "C:\Program Files\OpsHub Visual Studio Online Migration Utility\OpsHub_Resources\HSQLDB" to some other directory.
- Now go to the location "C:\Program Files\OpsHub Visual Studio Online Migration Utility\OpsHub_Resources\HSQLDB\opshub" and delete the "opshub.lck" file, it might be possible that this file may be in use by some other process, so delete the file forcefully.
- Start the migration utility, if above mentioned reason was causing the failure then after perfroming mentioned steps, you should be able to view migrations progress.
and if the error persists then please zip up and send us the log files from location "<c or d>:\Program Files\OpsHub Visual Studio Online Migration Utility\logs" and email them to firstname.lastname@example.org.
We are having a our migration fail due to the same issue described here:
We have about 40K changesets. Our repo is about 130GB in size - so not exactly tiny. We have about four years worth of TFS history that we'd like to migrate. We are only migrating source control items.
I'm happy to send through our log files if that helps you resolve the problem. I'm also willing to discuss directly if you need any help reproducing or fixing this problem.
Hi Nathan, Could you please verify that whether there are any files or folder whose full path name exceeds more than 252 characters in size for the failing changeset, do you have antivirus installed (if so can you please disable it and retry).
Else Can you please zip up and send us the log files from location <c or d>:\Program Files\OpsHub Visual Studio Online Migration Utility\logs and email them to email@example.com.