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.
Not so disappointed in the tool as in the delivery. The free version (Utility version) does a lot but if you need on-premises or some other features you need to go to the commercial version. I have no problem with that except my quote to license to migrate 2 team projects was $10,000. No services, just the tool for me to use. That's a big jump from free for two team projects, especially when in the month before there was a special MSDN price at 50% discount - $2500 initiation fee + $875 per project. (I was a month late for that- so be it) Then my quote for 5 projects in March was $5000 + $1750 per project (normal list price) but when we decided to only license two projects it became a $10,000 minimum. $1,500 more than what was starting out as the published list price.
I've used the tool for a few clients in the past and each time I've had to rely on either destroying problematic branches, using the TFS Integration tools for projects that just wouldn't migrate with OpsHub and terrible performance when the source project had many branches.
Combined with the new commercial model I have a hard time recommending the Migration Tool as my first go-to solution. If it works, it's great if it doesn't you're in for a lot of pain.
Given the slow performance on larger projects be sure you do not rely on the ability to "catch-up" after the original migration has finished. That ability used to be part of the free solution but no longer is.
All in all, great tool for smaller projects that haven't been around since TFS 2008 and before (too many issues seem to stem from the old slotmode vs itemmode) and when you want some change history or are willing to pay. Not recommended for "real life" projects unfortunately.
The utility has been used to migrate some very large projects. The speed of migration depends on a variety of factors, like hardware infrastructure, network speed/bandwidth, TFS response times etc.
Proper & comprehensive handling of branching does require complex processing to ensure proper handling in every situation. From our review some other tools don't have correct behavior in complex cases.
Please raise a question here or start a new conversation on stackoverflow if you have any errors while using the utility.
The commercial model of utility has changed over time from supported by stakeholders to supported by end customers.
Update: Thank you for the suggestion, I increased the memory to 4096. The migration went on, but after a while I got this error message at 13634/46483 Changeset(s)/Label(s) passed
Error in execution of Job : <our TFS> to ourproject.visualstudio.com| <our TFS> to ourproject.visualstudio.com| TFS Source 1460104824117 Source TFS 1460104824118 'PROJECTNAME' Commit Information <our TFS> to ourproject.visualstudio.com| TFS Source 1460104824117 Source TFS 1460104824118 TFS Commit Information OpsHub-012300: Error occurred in generating events. Caused by Error in getting All Change Events : OH-TFS-Connector-0030: Error occurred in executing operation getTotalRevisions. Server Error : TF14098: Access Denied: User <My domain user account> needs Read permission(s) for at least one item in changeset 148560.
I am the project admin and member of the actual project and there is no Changeset 148560 in the project. TFS does not find this Changeset in this project. The latest changeset number of the whole TFS is 148555
Having successfully migrated several of our team projects’ source with the free version, we engaged OpsHub to see if they could support an advanced mapping scenario involving moving 8 on-premises TFS 2010 team projects’ source code (with history and thousands of branches) into one new VSTS project. They delivered a solid proof-of-concept demo of the OpsHub Integration Manager (OIM) tool almost immediately, and we proceeded with mapping configuration and validation of the myriad transaction types. Timely hotfixes were delivered as necessary, and the product demonstrated its flexibility to resume changeset processing from where it had left off. The overall customer service experience was stellar; the professional services and support teams have dedicated individuals. Meetings were flexible during our business hours, and any issues there weren’t immediate answers for were diligently researched and reported on the next day. Migration stats: -~96,000 changesets (6+ years’ worth) -~3,500,000 file revisions across those changesets -Changesets ranged in size from a single file to 300,000+ files -28 days’ processing time for the production run from start to live “catch up”
This is downloading version 1.3 but the description says 2.0. I have just tried installing the 1.3 version and it tells you once installed to install the new version in a registration email. I have been struggling for a week with the old version with errors and then just generally too slow. Fingers crossed this is a big upgrade with V2. UPDATE***Started using this and they have removed the ability to select more than 1 team project to migrate at a time. Lowered rating in response.
Smaller project code and history seems to work, eventually. I've had no success with work items regardless of Agile or Scrum workflow. There seems to be no way to import any custom templates.
As the existing TFS 2010 server is creaking at the seams, I had to run from a separate machine which didn't help the performance issue. I'm about to try on a dedicated more powerful box, importing one project at a time but I'm starting to think copying only the code with no history manually and loosing the workflow is going to be our only option. How Ms can release an upgraded TFS with no fully supported method of migrating existing data is beyond me. What's next? New Office which cant read any previous word or excel docs?
Not receiving any verification code via email. Checked inbox and spam. Also don't know how to re-run the application. Can't find it in start menu. If I try to re-install it just disappears after the standard permission elevation warning. Think I'll stick with on premises.
Seems pretty poor - can't even install since it asks for a verification code that will be emailed to the address you enter but no email ever arrives (I've checked all spam folders etc...). Need to implement a better method of providing verification as this is basic stuff.
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.
We have a single monolithic TFS2015 project and I'm attempting to migrate a subset of the work items defined by an Area Node and its own Iterations (only work items, no VCS). I was going to do this via a query which selects the desired work and then using the Team Excel Plugin to copy/paste to export/import. I knew I'd lose all the timestamps but I wasn't expecting that I'd only be able to import everything in a New/ToDo state. That poses a great problem for all our WIP and completed work. I was hoping your utility would allow me to migrate this subset of the project to a new project in VSO (different project name). It appears the utility will only allow you to migrate the project in it's entirety.
We migrated successfully several projects from TFS 2015 (14.0.23128.0) to VSO with OpsHub.
But the biggest project migration stopped with a failure: Error occurred while sync. No files checked in.
The issue is reproduced several times. Is there some workaround?
A sample of a log file (more of log file info is here: http://stackoverflow.com/questions/37345779/opshub-version-2-2-2-001-oh-scm-009-error-occurred-while-sync-no-files-checke):
WARN Non-fatal failure: The item $/Extensions/Administration/ME2/Views/TreeView.ascx.cs could not be found in your workspace, or you do not have permission to access it.
DEBUG Actually Editing - 69 files from 70 processed.
ERROR Error occurred in thread of CheckinAll:TF10141: No files checked in: resolve the conflicts and try again.
at Microsoft.TeamFoundation.VersionControl.Client.Client.ReportCheckInConflictsFailuresAndThrow(Workspace workspace, CheckinResult checkinResult, Failure conflicts, Failure failures, Boolean noAutoResolve, Int32 operationId)
at Service.Adapters.TFSCheckinWorkspaceContext.checkin(String comment, WorkItemCheckinInfo workItemChanges, List`1 otherCheckInProperties, String checkinUser) in d:\viral\checkout\OpsHubV2\TFSWCFServiceSource\Service\Service\TFSVersionControl\AdapterComponents\TFSCheckinWorkspaceContext.cs:line 2691
at Service.Adapters.TFSVCAdapter.checkIn(List`1 checkinItems, String checkinComment, String checkinUser, List`1 workitemId, List`1 otherCheckInProperties, String uniqueId) in d:\viral\checkout\OpsHubV2\TFSWCFServiceSource\Service\Service\TFSVersionControl\AdapterComponents\TFSVCAdapter.cs:line 125
at com.opshub.tfs.test.TFSWebService.<>c__DisplayClass6.<CheckInAll>b__4() in d:\viral\checkout\OpsHubV2\TFSWCFServiceSource\Service\Service\TFSWebService.cs:line 1034
We are trying to migrate work items and source code from our TFS on-premises to Visual Studio Team Service (VSTS). We are using OpsHub V2.2.0.000.
After we set Endpoint details and Migration details, on page "Migration Project(s)" we get error message "Requested value 'CreatePending' was not found".
We have created VSTS project with the same name as it is on TFS on-premises. For process template we are using SCRUM. On our TFS on-premises we set custom process template that is inherited from SCRUM.
We are logged-in with user account that has owner access rights.
Visual Studio professional 2013 (update 5) can connect to VSTS and display all project.
We tried to do the same procedure with another VSTS account, and OpsHub did not show the error message, it passed to the next step. After that we compared those two VSTS accounts, and found out that process template versions were different. First account had Agile v14.5, CMMI v14.6 and Scrum v14.6, but second account had Agile v14.4, CMMI v14.5 and Scrum v14.5.
Process template versions are different. Based on that, we can assume that Microsoft has updated some VSTS accounts, but some has not yet.
Do you have any idea why we cannot migrate source code and work items to our first VSTS account?
From log file:
"2016-04-27 12:05:22,525  ERROR Requested value 'CreatePending' was not found.
System.ArgumentException: Requested value 'CreatePending' was not found.
at TFSMigrationUI.ViewModel.ProjectSelectionViewModel.loadProjectWorker_RunWorkerCompleted(Object sender, RunWorkerCompletedEventArgs e) in c:\Project CheckOut\TFSMigration\TFSMigrationUI\ViewModel\ProjectSelectionViewModel.cs:line 381
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)"
Since a couple of days, when VSO account is created, default collection now have the same name as the account and not "DefaultCollection":
- Use to be https://accountname.visualstudio.com/defaultcollection
- Now: https://accountname.visualstudio.com/accountname
This result into a faillure "Page not found" when starting a new migration. I've been able to fix the issue by redirecting service urls using fiddler: url.Replace("/accountname/Services/v3.0/","/defaultcollection/Services/v3.0/" but then tools is crashing with error "Instance not set to an instance of an object".
Newly created account or account with name changed is impacted.
Any suggestion or code fix would be strongly appreciated.
The migration stopped with this error.
Error in execution of Job : <our TFS> to ourproject.visualstudio.com| <our TFS> to ourproject.visualstudio.com| TFS Source 1460104824117 Source TFS 1460104824118 'PROJECTNAME' Commit Information <our TFS> to ourproject.visualstudio.com| TFS Source 1460104824117 Source TFS 1460104824118 TFS Commit Information
OpsHub-012300: Error occurred in generating events. Caused by Error in getting All Change Events : OH-TFS-Connector-0030: Error occurred in executing operation getTotalRevisions. Server Error : TF14098: Access Denied: User <My domain user account> needs Read permission(s) for at least one item in ChangeSet 148560.
I am the project admin and member of the actual project and there is no ChangeSet 148560 in the project. TFS does not find this Changeset in this project. The latest ChangeSet number of the whole TFS is 148555
After a while the migration goes on, but around 50% same error happened with another nonexisting ChangSet. And secondly the migration doesn't go on anymore.
Is this behavior exist in only the free version of the migration tool? Is there any chance that the paid version can migrate our TFS to VSTS?
Hi, can you share the logs of the migration run from : C:\Program Files\OpsHub Visual Studio Migration Utility\logs to firstname.lastname@example.org. We'll analyze them and help you solve the issue.
This isn't a free/premium variation issue.
We have a proxy error : "Unable to connect to remote server..." when we try to install OpsUb Visual Studio Migration Utility. We have correctly configured our proxy settings with a _JAVA_OPTIONS env. variable but the error still occurs. (http://www.opshub.com/main/ovsomu-proxy)
Now, we try to bypass the proxy with a specific rule but we need more information about the destination URL that the installation file tries to reach.
Could you help us with that,
Thanks a lot !
It seems that your machine is behind a proxy and all traffic in-out is being routed through it. (Including the communication of local traffic) You will have to bypass local addresses from the proxy as well as enable OVSMU to communicate through the proxy.
Please refer the C:\Program Files\OpsHub Visual Studio Migration Utility\Other_Resources\Resources\ProxyUtility.zip to configure OVSMU to utilize your proxy. There should be a user guide document which lists the steps.Keep the bypass local address value as default
I have a used a few versions of the tool and it always marked file history with the user who made the original checkin, and an additional comment like so was added, to original check in comment(Originally checked in by domain\user on 2014-07-23 16:55:13.583 as Changeset 128024).
The latest version of app, marks all history comments as done by the user, that the app is using to connect to VSO, and does not add the additional comment of when it was originally checked in.
Why do I need to map any users if the tool wont use the information I am giving it? If I am mapping users I am expecting that information to be used to place the history of the user into that user.
How exactly does the premium version use the user mapping information, is there a screen shot of the changeset history that I can see so I can compare it to what is happening now?
After looking back over the descriptions on both this site and your own, I see that One to one user mapping is listed as a feature of the free version. If this is not the case would you please update the sites.
The one-to-one user-mapping as described in the feature list is for User Fields of work-items where as per mapping, the values are set.
In premium version it is additionally used to perform impersonation (performing the action using the same user as that of source)
The user mapping interface is inside a unified user experience flow of input hence, even for a version control only migration it is still taken.
Getting below error after running long time.
ERROR Error occurred in thread of CheckinAll:O:\w75_14\xxx\xxx: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host
at com.opshub.tfs.test.TFSWebService.CheckinAllStatus(String authToken) in e:\trunk\OpsHubV2\TFSWCFServiceSource\Service\Service\TFSWebService.cs:line 958
can You please help us, how to resolve
The tool must be failing for a changeset. You should be able to find the changeset number from the 'View Failures' page. Can you use your Visual Studio to connect to your Source End Point and through Source Control Explorer, try to perform a 'Get Specific Version(s)' for the changeset number that you obtained from the tool? Can you confirm if you are getting the same error?