Visual Studio Online is Microsoft’s cloud based application lifecycle management service. It replaces what used to be called Team Foundation Service and provides source code control, test management, task management and continuous integration services.
Visual Studio Online provides a subset of features available on premise. For example, Lab Manager and SharePoint portals are not available and there are limits on template and report customization.
One of the key challenges in adopting Visual Studio Online is that there is no current migration path if you want to move back to Team Foundation Server on premise.
For migration of one premise TFS instances, there are a couple options including migrating databases and/or using a tool called the TFS Integration Platform. However, this tool does not current work with Visual Studio Online successfully to migrate off of that platform.
The lack of a migration option has been identified as an issue by Microsoft and there is a new blog post from Brian Harry, who is the Product Manager for TFS, that details a newly proposed one-time migration process for those who want to move off of Visual Studio Online.
The key details are as follows:
Early adopter status has been extended to May 7, 2014.
Migration requires you to contact Microsoft by email at no charge.
You can only migrate to a TFS 2013 Update 2 server.
Migration is only available as a one time feature and will be available only for 6 weeks.
The key challenge that the VS Online team has is that with the speed of their release cycles, keeping up with schema changes and mapping them from the latest VS Online version back to TFS 2013 is complicated, requires extensive testing, and deployment.
I’d very much like to have a permanent export feature – I think there are lots of scenarios that it would enable, and I haven’t given up on getting there. However, going into the the implementation of this capability we knew it was going to be very expensive. The big problem with it is that the service upgrades every 3 weeks but the on-premises product can’t. That means that when we export, we have to “downgrade” or transform the schema from the then current schema on the service to the schema that was supported in some version (realistically, the most recent) of the on-premises product. That means, for every feature we build, we must not only build the feature and build the upgrade path but we must also build the downgrade path. And building the downgrade path isn’t the most difficult part – it’s validating it on a large enough set of real world customer data to make sure that it works reliably.
At this point, we know we have some large schema changes coming this summer as we enable process customization and other important features people are waiting for. We are not going to be able maintain the the “downgrade” code path through those changes. I don’t like it and I’m sure I’ll get my share of comments reinforcing this but I believe it’s a call we need to make. To manage through this, we have decided to scope the capability, for now, to aiding people through the transition and will consider doing more later. I’m not making any promises but will certainly listen to feedback over the next year.
So if you are evaluating VS Online as a mid-term to long-term solution, be aware that migrating off of it may be a challenge in the future. If you are currently online and want to migrate on premise, make sure you take advantage of this one time migration program when it is announced.
