Company that I have worked for was all way long Microsoft shop. They used TFS as first class citizen. We have been through 2 or 3 updates, which always brought more surprises that we wanted (mainly because of side dependencies). 2 years ago I mentioned that maybe we could go to cloud solution. It was named VSTS back then, (currently Azure DevOps) and basically it’s a cloud version of TFS fully maintained by Microsoft. At first the idea haven’t been accepted, but seed has been planted.
A small disaster
Few months later our TFS server crashed big time. Normally it would mean restoring full os image, unfortunately, we discovered that for some reason images were corrupted. We lost like 4 days of work, which partially was recovered (code) but all other modifications from that period were lost . Migration to cloud was on the table again. We decided that we will do a test migration, gather some knowledge and make final decision afterwards.
The preparations
Microsoft gives a TfsMigrator tool and provides very good migration guide. I highly recommend to read the guide. Depending on the version of your on-premise TFS your migration will differ. In our case we had to bump the TFS version to the latest one and modify quite a few process templates.
I strongly recommend that you will script all the steps, especially if you have been using TFS for few years. Also, since migration needs few weeks of preparations, it’s best to clone your production server.
Proof of concept migration was ready within a week and a half, results were very promising. Everyone believed that it will work, then things got little bit more complicated. Company decided to change the support provider and create new ActiveDirectory domain. It added a lot of extra testing but we managed to fix all the issues.
Success
Finally the date has been settled, company has been migrated to new domain, TFS was migrated to VSTS. Users has been properly mapped. First 2 weeks we were resolving issues like someone not having access to the repository or to the projects. Some process templates had to be fixed after the migrations. Luckily all those things were quite easy to resolve. Today we are almost a full year after the migration. So we can give a honest opinion on the good, bad and ugly.
The good
- During the migration we discovered that we had few servers that were running (and paid) but not used. So as a side effect we got rid of them.
- All the marketplace extensions were finally working
- we replaced external services with what Azure DevOps provided (MyGet)
- our on-premise server was accessible only through internal network, Azure DevOps increased ease of access
- burden of updates is gone (!!)
- backups testing is gone (!)
- operating cost is down (!)
The bad
Really, not much. At the beginning our Azure DevOps instance got heavy usage (probably everyone was downloading repositories and stuff ) and we got some warning messages that we are meeting our quotas.
But this was only on first 1-2 days, after a year of using it we had like one or two degraded performance issues. But they were quickly resolved as this was a global issue for Azure DevOps.
Summary
Are we looking back with remorse? There is only one possible answer: NO
It was a change for the better in every possible way.
Not having to think about updates, backups, missing features, Easy integration with external services, better security.
How much do we pay for this? We have around 45 developer accounts. 37 stakeholder accounts. So this is not little but also not gigantic. Still we currently pay for it around 5eur/month in total. This is mainly because most of the paid accounts are part of Visual Studio MSDN subscription which you will be given “free” if you have few MS certified developers.
For comparision, our on-premise server was costing us around 50 EUR/month (around 56 USD) for server with 2 daily backups (which got corrupted anyway). Also you need to add external services that we paid for like MyGet (400EUR/year, replaced by Azure DevOps nuget module) and TeamCity (600EUR/year if I recall correctly).
Also you need to include extra man hours spent on maintaining the server, TFS updates, checking backups (we didn’t check and paid double price later :/) so I would assume at least 20h a year, which will translate easily to 600EUR. So our on-premise server was costing us at least 2200EUR/ year. .
I remember the times before the update. We often had to give answers to our colleagues that “this feature will come in next TFS update”. Effectively it meant a wait of 6+ months.
I’m sure that migrations is the kind of job that nobody wants to do in the company. Typical argument is that it will be less secure that our internal server. But in reality, have you made an security audit of your server? Do you make those audits periodically? How much does it cost to make that kind of audit? Do you have the latest security updates installed?
I believe a lot of smaller companies can easily answer no to most of those questions.
There is also one additional effect of having everything under one hood:
it’s easy to grant/take access. Think of how many external services you have. You probably granted access in so many places that you don’t even remember now.
When an employee leaves the company you should walk through all of those services and deny access. Have you done this? Every time? Maybe you missed one or two services?
Maybe person who left your company a year ago still has access to your CD setup? Isn’t that scary? Go fix that, and better get it all under one hood. It’s so much easier.
