Software changes. As facts of life go, that one’s pretty cut and dried, and most of us are used to it.

But sometimes software that’s central to the core of your business – such as the version control solution that safeguards your entire product line – abruptly changes, and suddenly you need to rethink the way you develop, store, and plan your code. These are the kinds of decisions that make you wish you’d listened to your Mom and studied dentistry.

Early last year, Microsoft announced it was retiring support for Visual SourceSafe (VSS), one of the most popular source control tools ever created. Development had gradually been winding down for years, as Microsoft shifted strategy to a more ambitious money-maker, Team Foundation Server (TFS). But the install base of VSS remained huge, and the switchover to TFS, especially among smaller development shops that were clearly not the target for an enterprise tool like TFS, hasn’t been as rapid as Microsoft may have hoped.

So to signal users that now is the time to make a switch, Microsoft will stop supporting VSS in June 2012, officially rendering the product obsolete. For the tens of thousands of users who still rely on it, this is a little like being told their pacemaker will stop working just as bikini season opens.

What’s the right thing to do? If you’re like many of those users, your strategy has been to delay. Let’s face it, VSS may have its warts, but up to now it’s done the job.

But while it may be okay to rely on that old VHS player in your basement, rather than upgrade all those Disney videos to Blu-ray, keeping an obsolete solution at the heart of your corporate development process is a Bad Idea. No support means no new bug fixes, no upgrades when the latest version of Windows rolls around, and no tech support. As every good IT guy will tell you, the key to a good Mission Critical Solution is having a vendor you can get out of bed at midnight when disaster strikes.

Bluntly, if you haven’t done so already, the time to replace Visual SourceSafe is now. There’s a wide variety of modern source control tools to choose from – many with significant advantages over the way you’re doing things today – and skilled professional help for a smooth transition.

To understand the choices we’re faced with today, it pays to look at how we got here. In the early 1990s One Tree Software revolutionized version control with SourceSafe. Source control was still relatively new as far as established procedures went, but when Microsoft bought One Tree in 1994 and put real marketing weight behind SourceSafe, all that changed.

SourceSafe was revolutionary in many ways, especially its great Windows support and friendly user interface. Just as importantly, it was distributed by Microsoft as part of nearly every MSDN subscription, which put it into the hands of many developers who had never used source control. It won hearts and minds and quickly became the de facto standard.

From a modern perspective, SourceSafe had numerous problems. Perhaps chief among these were its lack of atomic check-ins and its reliance on Windows filesharing, both of which contributed to gradual data corruption. If a check-in fails for any reason, atomic check-ins make sure no files are changed, ensuring the repository is not left in a partially updated state. Without them, the next user can grab a mix of old and new files. Before you know it, a simple network hiccup can lead to a rapidly propagating version control nightmare.

SourceSafe was also designed before the explosion in internet usage, meaning it wasn’t built around a modern client/server model. That left users who wanted to access code remotely out in the cold.

My company, SourceGear, got its first big break when one of our developers here in rural Illinois, tired of being unable to check in code at home where he could feed his chickens, wrote a remote client for SourceSafe in 1997. It worked so well his chickens grew fat and happy. Plus, we were able to turn his chicken-friendly add-on into our first commercial software hit, SourceGear SourceOffSite, the first tool that allowed developers to access a Visual SourceSafe database over the Internet. It still sells well for us today, over a decade later.

SourceOffSite was our first toe in the water of the SourceSafe ecosystem, but pretty soon we were clutching an inflatable duck and captaining a life raft. To fully service our customers, we had to become experts in the inner workings of VSS, and especially the kinds of problems that caused the most heartache. Over the last decade we’ve assisted countless customers to diagnose troubled and corrupted VSS databases.

He Didn’t Jump, He Was Pushed

As a consequence of Microsoft retiring support, there is more urgency to migrate away from VSS than ever before – but also more and better source control options for you to choose from.

Frequently our customers come to us looking for a painless rollover. They simply want to be up and running again with a new source control solution, with the shortest amount of downtime.

That’s understandable, and with the right VSS replacement and technology partner, entirely achievable. I’ll discuss some of the best options for you to get underway with a VSS replacement quickly in the next section. But at the risk of being predictable, I’d suggest you take a minute to look past your immediate pain, and think a bit about what you want your version control solution to be two, five, even ten years from now. Considering how many customers we have who’ve been using VSS for over a decade, that’s not as far-fetched as it may seem.

For example, one recent trend has been towards products with integrated source control and bug tracking, which many have found not only makes tasks easier, but also helps dev teams standardize on one tool and work a little more collaboratively. Most of us are still waiting to see the benefits of ALM (Application Lifecycle Management), with its promise of integrated dev, test, and build environments (and associated Cadillac price tag), but the marriage of version control and bug tracking makes sense.

Another recent trend is the move towards distributed version control solutions (DVCS). A DVCS differs from traditional version control in that it has no central server, and users can share change-sets peer to peer. It can bring with it a sometimes radical change in development methodology – particularly for those who approach a merge with all the enthusiasm of a root canal – but it can also bring tremendous benefits. Unfortunately, virtually all DVCS’s on the market today, including Mercurial and git, are not ready for the larger corporate market, lacking in things like user accounts, file locks, and an enterprise license agreement.

In the absence of a solid DVCS choice, most customers we work with today choose one of three products: Subversion, Microsoft Team Foundation Server, or our own VSS replacement, SourceGear Vault Pro. All three are solid choices, but they are by no means the only ones. For now, I’d like to focus on the issues involved in migrating away from VSS to a modern replacement.

The Big Move

The move to a new version control solution is a little daunting for most teams. It costs money, it’s risky, it upsets established routines and, worst of all, it means developer downtime. And even with the most carefully planned move, the amount of downtime can be unpredictable.

Even so, none of that is as bad as you think. There are modern version control solutions for every budget, from high-end systems designed for global enterprises (like TFS) to free open source solutions (like SVN and Mercurial). A well-planned move – and common sense backups – will help reduce risk. And perturbing the way your developers work can be a good thing, especially if it means they start working more efficiently.

For most teams the real hurdle is developer downtime, not just the time required to prepare and import a 30 gigabyte source code repository, but the effort it takes to train a team on the new tool. For most, downtime of more than a few days is ultimately far more costly than writing the check for the software, or professional services during the install.

Fortunately, there’s good news here as well. With the right approach, switching can be a lot more painless than you think.

First, you need to get past the fact that there is probably corruption in your VSS database, possibly substantial corruption. For most of our customers, the import process is the first time they see the extent of the damage to their repository. Frequently, this induces panic. What does this mean for the integrity of their source code? For future development?

Usually the panic is unjustified, and regardless of the degree of the damage, it’s always better to address the problem sooner rather than later. Once they finish the import and resume working, the panic subsides for the vast majority of our customers, and they quickly move forward with a solution that prevents any further data loss.

Most solutions also have VSS import tools. We’ve spent years refining our import tool for SourceGear Vault, and it’s obvious the competition has done the same. Most of them will give you a good indication of how long the import will take, with steady updates along the way.

There are also alternatives to doing a full import. After years of helping customers with imports, we explored one alternative with Vault’s VSS Handoff tool. VSS Handoff is essentially a continuous window into your VSS repository. It imports the latest version of every file and gets you up and running immediately, while still maintaining links to your old history, shares, and pins in the SourceSafe repository. It’s one way to do a safe VSS import in minutes, and can have you underway with your new version control solution in hours, even with the largest repositories.

Finally, if you do run into problems, assistance is available. At SourceGear we’ve helped numerous companies untangle thorny VSS import problems, and we’re not alone. Many IT consulting shops have also developed solid expertise in VSS, and can help you get through the tough spots with a modest number of billable hours.

Ultimately, the technical details of what import approach to take – and the best way to deal with problems – will depend on what replacement tool you’ve chosen. Since we can’t really avoid talking about that, and since SourceGear is also a player in the space, I’ve decided to discuss only those VSS replacement solutions we usually recommend, and focus chiefly on the strengths of each. Comparative information on other tools is obtainable on a number of blogs and commercial websites.

The three replacement tools we most commonly recommend for VSS users are TFS, SVN, and Vault Pro. Each is a solid choice, with its own strengths and weaknesses. The questions we’re most frequently asked are, “Which of these will allow me to get up and running the fastest?” and “Which has all the features of VSS, including Share and Pin?”

With that in mind, here’s a high-level feature comparison chart, starting with the key features of VSS that users frequently miss the most when they adopt a new tool (such as Share, Pin, and Shadow Folders), and continuing with the new features that gain them the most (such as shelve and integrated bug tracking).

Feature Comparison of Popular VSS Replacement Tools

Microsoft TFS is an excellent choice, especially for large teams. It’s Microsoft’s future, and they’ve made a substantial bet on its success. That means it’s well funded, with some nice reporting tools, and a lot of nifty new features such as Branch Visualization. It also scales well, handling teams of 1,000 developers, or more, better than any other tool on this list.

Subversion is another popular choice, and for good reasons. Unlike TFS, it’s completely free and has more modest install costs. Many larger companies that typically steer away from open source have embraced it, partly because of its excellent community support and reputation for reliability. While its cross-platform support was once criticized as shaky, this has improved significantly in the past five years.

SourceGear Vault Pro was designed from the ground up as a VSS replacement tool, with a deliberately familiar user interface and support for all of VSS’s features, including Share, Pin, and Shadow Folders. SourceSafe Users can transition to Vault and work the way they always have, with less time lost on the learning curve. Vault is the only tool to offer the VSS Handoff feature, which gets you up and running immediately, cutting actual downtime to a few hours.

Which tool you choose, and what strategy you use to minimize the risk and downtime associated with switching version control solutions, will ultimately be dictated by your unique set up and requirements. But I hope I’ve illustrated that there is a VSS replacement option that will fit your needs, and that there’s no reason to put it off any longer. The time to upgrade is now.

SQL Source Control can be downloaded from the Red Gate website.

The time to upgrade is now. Try SourceGear Vault for free – the only tool with VSS Handoff