SWOT analysis of Visual Studio Online

Deciding to go with a tool like VSO, for a company, is not easy. There are several alternatives, including free ones, that give you just as much, maybe even more - in terms of pricing and/or flexibility. So, in order to get our team to use it (or not), I prepared a SWOT analysis (Strengths Weaknesses Opportunities Threats). I wanted to make it available so that it might help someone in a similar position make their case.

The Process

Visual Studio Online does not allow any major process customizations (yet), although it is by far one of the most requested features. Do note, however, that the feature is now planned, which means that it should see light of day in the semi-near future. Now, that said, it means that before you dive into SWOT analysis, you need to understand how your process is established in your development team. If you are using a fairly plain-old Agile process, like SCRUM, you should have no problems using the built-in template. Same goes for the classic template that was in Team Foundation System before.

In our case, we actually have two separate processes established. One is a content process and the other is the development process. They are formally separated, which gives the team a bit more options on which tools to use to support the process. We decided to opt for a simple, no modification, Agile/Scrum process.

Wishes

The team made a couple requirements/wishes before we set out to analyse different tools:

Must support Continuous Integration with Azure fairly easily / out of the box (spoiler alert: http://azure.microsoft.com/en-us/documentation/articles/cloud-services-continuous-delivery-use-vso/)
Must enable the team to request/perform Code Reviews. Code annotations in the source are nice to have, but not required.
Must enable the team to link check-ins to work items
Must enable the team to have control over build process (this was an older wound we had :-) ...)

Strengths

Does not require extra investment - with our MSDN subscriptions, Visual Studio Online is already licensed. Additionally, if we wanted, we can add 5 "basic" members for free, and an unlimited number of stakeholders (people who can only view the project). Also, we don't need to set-up and maintain any new hardware or virtual machines. We also don't need to invest any resources into configuring an on-premise server (backup, security, maintenance, etc.). There is a pricing "catch", related to Build time, that can be offset by configuring an on-premise build controller, so some HW investment is required but can be weighed with the price of a build hour.
Supports all our wishes/requirements - this one is obvious, but things like Code Review, CI etc., are supported out of the box + many more.
Constant****upgrades - we never have to worry about being out of date. New features are being rolled out regularly to VSO, and we want to be on that train to save time.
No need for VPN - VSO does not require a VPN to connect and work. This means our team can work remotely much easier, even in places where VPN access is blocked, but ports 80 and 443 are opened. Also, it means we are not tied to our infrastructure...

WEAKNESSES

Constant upgrades - Microsoft is not perfect. So, while it's mostly a good thing to have new features, it can also be a problem as new bugs can be introduced that may hinder the development. However, this is offset by the reputation that Microsoft has to uphold. Imagine what would happen if all the organizations on VSO would be unable to do their work? That's right...
SLA only guarantees 99,9% availability - There are very few cases of VSO being offline (http://blogs.msdn.com/b/vsoservice/) for the same reasons as described above. However, if it were to happen, we are able to develop offline without major problems for a couple hours.
Does not support process customization - if we want to modify it, we can't yet. However, in our case, we don't need to anymore as we've tailored the process to what is available. Our justification for this was: "If it's good enough for everyone else, maybe we shouldn't complicated."
Does not support migration back to on-premise - Technically, there is no supported way of migrating back to an on-premise server if we ever decide to go back. As we'll see later, this does not mean there is no way at all but it's not a simple "click here, then there" type of task.

Opportunities

Faster Development Cycle - Because it integrates directly into the tools we use daily (Visual Studio & Azure), it means that team productivity should improve. It means less jumping through hoops to make certain things happen (e.g. linking check-ins with Work items, or rather, seeing changes introduced by one work item). We used Jira before, and we had an internal policy of writing the changeset number into the comment...
Quicker Identification of build errors - Setting up a CI build with the on-prem TFS we used thus far was a bit complicated because the version was outdated. That meant automatic deploys to Azure environments were impossible (in terms of effort required vs. gain). VSO is fully integrated with Azure in this department, and additionally, it allows connecting an on premise build controller.
Improve the release management process - It also allows connecting to tools like Release Management, and Microsoft Test Manager, which means our existing processes can be vastly improved and sped up.

Threats

No code backups - technically, you can't migrate back to on-premise servers without loosing your revision history. However, Microsoft has already mentioned a potential solution for this on their blog. It might not be publicly available, but from what we understood, there is some support available for this migration. In any case, code backups can be mitigated by regularly creating "drops". It's not ideal, but can help solve some part of the problem.
Moving code to non-company-owned servers - This is a big one. Having code located outside the company can be perceived as a threat. However, code ownership and all legal rights are explicitly retained by the author/owner of the code and no ownership is implied by Microsoft in the legal agreements. Additionally, Microsoft is ISO 27001 certified. The ISO 27000 family of standards helps organizations keep information assets secure. Also, in terms of security and backups, we are confident that Microsoft has, compared to our team, an almost infinite number of resources at their disposal that make sure VSO is protected from things like DDOS attacks, hacks, etc. Our code should be as safe, if not safer. Keep in mind though, the major threat to code theft, are still humans. This is solved using legal tactics, not technical measures.

In the end, we decided to evaluate VSO for our team and are using it to see if our analysis proves correct. I hope the above points help someone from another company make their case, one way or another.