We are moving from on-premise tfs 2012 to the visual studio online environment.
For this we need to move a lot of projects, most of them aren’t a problem with the free opshub tool.
But 2 of our projects are really big and the tool would take about 8~9 days to complete the migration, which is too long for us.
What I would like is the following:
Start the migration from on-premise to vso
Keep working in the on-premise
After the migration has finished, migrating the commits that were made in the last 8~9 days.
I’m not sure the free opshub tool supports something like this.
Is there a way to do this with the free tool? If so how does this work?
That is feasible. You just start the migration initially, as your initial run is completed, and the status of migration goes to not running, you go the View Progress page, and start the already configured migration.
This will pick the newly added changes, that were done to the on-premise instance, after the actual migration started.
Note: You will get a process vs total revision count mismatch in status page in such cases, as total count is not calculated only once at start of the migration.
Related
I am trying to see how the OpsHub migration tool works before I perform real migration.
And hence I am trying with a on premise TFS instance and a trial created Team Services (was Visual Studio Online) instance. but when I finish configuring the stuff and it start to validate all the settings put in, it is giving error for Team Services Project Collection URL. It is taking collection URL as
https://********.visualstudio.com/********
where as it should only use
https://********.visualstudio.com/
Not sure how to get over it and now fully stuck.
This is caused by the change in VSTS:
Collection in the domain
Your Team Services account URL just got 18 characters shorter. We’ve
removed “/DefaultCollection” from the path. While it’s small, but
welcome change. It’s the beginning of a larger journey to how we
structure accounts. Learn more here.
Note that existing accounts will still give out the longer URL for Git
Clones in the Code hub. This is because to use the new shorter URL in
VS, you will need to reconnect Team Explorer using the shorter URL.
Today you either need to use the long or the short URL for an account
in VS, you can’t intermingle. Once we have enough clients updated such
that they just work seamlessly with either type, we’ll change the
default Git Clone URL to the shorter one as well.
Last but not least, we have a set of Release Management improvements.
Please download the latest version of OpsHub Visual Studio Migration Utility and then try again.
A similar issue here: OPS Hub - unable to migrate project.
We have some huge changesets that are causing our migration to grind to a crawl. I am wondering if we delete those folders from the project, will OpsHub still migrate the changesets for the delete folders?
Destroying folders will remove them and all their history (in that path) from the version control data store. OpsHub won't be able to find the folders and as such will not migrate them (they don't exist). You will have to restart the migration. If folders have been renamed, you may need to destroy the data under the old name as well.
Deleting folders won't exclude them from migration. OpsHub will replay all actions and will detect these changes and their history. It will migrate all changesets for the folder up to the final delete.
You can also speed up you migration a lot by destroying old branches (branches cause a lot of drag on your migration). If you have old branches or deleted branches that you don't need to transfer over, then destroy them. Especially Feature branches and old developer branches may not be worth the trouble.
You can also up the memory allocation for OpsHub to give it a little speed bump:
Close the migration utility.
Goto location C:\Program Files\OpsHub Visual Studio Online Migration Utility\OpsHubServer6.0.16\bin
open the file service.bat in notepad in editable mode. You may need to start Notepad as administrator to edit it.
search for the keyword -Xms512m -Xmx2048m and replace it with -Xms1024m -Xmx4096m, this will increase the memory for java, save the above changes (The numbers are for reference. You can set a higher amount of memory based on your available hardware)
Go to the location from command prompt C:\Program Files\OpsHub Visual Studio Online Migration Utility\OpsHubServer6.0.16\bin
Run the unregisterservice.bat from command prompt as an admin to unregister the service.
Let the above command execute completely then run registerservice.bat as an admin for registering the service.
Start the utility and start the migration
Running it on you Application Tier or on a machine that's physically close to the Application Tier also speeds up migrations considerably, as it shortens the network round-trips for one side of the migration to nearly zero. Since the Application Tier receives the most requests, it makes sense to put the migration there and not close to Visual Studio Team Services (by installing it on an Azure machine for example). Ensure that the AppTier has enough disk space for its version control cache.
Also monitor your SQL server closely, querying some of the branch history can be very CPU intensive, some SQL server settings can make a big difference. Ensuring that there are multiple TempDb files is one, tweaking MaxDOP can be another. See some tips on optimizing your SQL server for TFS here.
I've tried running the OpsHub migration tool to migrate TFS2013 on prem to VSTS. There's a couple of quirks I've managed to iron out, but the big two are:
Tasks are unparented in VSTS, the link wasn't preserved?
Tags aren't migrated
Has anyone else had this issue?
I believe that OpsHub are now charging extra for "preserving links" both between work items and between code and work items. Additionally I would not be surprised if Tags were on that list as well.
You should switch to the TFS Integration Tools, which are free.
They are a lot more complicated, cumbersome, and buggy but they work... Although there is only an old release it works with VSTS.
We are sorry to inform you but in the .000 release of v2.0 of our tool, there was a regression in Links and Relationship.
Can you please install the latest patch release ie. 2.0.0.002 from the Gallery and re-do the migration.
Links between WIT is still a part of the Free Version of the utility. :)
And we plan to support the 'tags' very soon for VSTS.
I'm using VSO xxx.visualstudio.com. We have to migrate with history to yyy.visualstudio.com. I know there is no direct tool. Looking for good approach or solution.
Unique Difference with, below question:
Visual Studio Online migration (VSO to VSO)
Export Source code with work Items
TFS Integration Platform tool is not working.
OpsHub company is taking too long to reply.
You can use the TFS Integration Tools to move TFVC code and Work Items from one Team Project to another regardless of TFS/VSO version.
I have done this a number of times and it works pretty well..
We have started making use of the OpsHub Visual Studio Online Migration Utility to migrate a few projects from TFS (on-premises) to Visual Studio Online (TFVC to TFVC).
We have now migrated two projects and in both cases the migration process has kicked off literally thousands of builds on our VSO build agents. The projects that it kicks off the builds for seem to be random (projects that are not part of the migration). In many cases the builds are CI builds that are running against commits from weeks/months ago. When the builds are started, the majority of the builds are being started on behalf of "Anonymous".
Has anyone else experienced this with OpsHub? If so, how do we get it to stop doing this? We have four more projects to migrate and we'd love to resolve this before starting another migration because it makes our build servers unusable while we kill the (thousands of) builds.
Thanks!
You'd want to either disable all of your build definitions until the migration is completed, then delete any queued builds and re-enable them or have NO_CI added to the comments to prevent triggering builds. I'd recommend just disabling the build definitions during the migration.
Please check to make sure continuous builds are not enabled for the projects or source collection which is being migrated.