Recently I had the opportunity to spend some time with a customer for whom we had just completed a migration. One of the things we discussed was the economic issues that went into their decision to migrate their application.
This particular customer had a home-grown "do everything" ERP app written in VB6. You can imagine, if you will, how something that started small--maybe as an Access database with a form or two and some reports--grew and grew until it consumed all business functions in the company.
This is not an isolated incident.
Apps like this are everywhere. In manufacturing, in health care, in financial services, agriculture, government. Everywhere. Being in this business as long as we have, we have seen a lot of this. Customers rely on those apps like I rely on coffee first thing in the morning--take it away and I simply cease to function.
But all good things come to an end and VB6 has been out of support for ever. Try to find someone under 60 who can work on your VB6 app. Just try. Your typical VB6 programmer today has 5 grand kids, a bad back, and wheezes when he coughs. So our customer, like many other companies, decided to bite the bullet and modernize this VB6 dinosaur.
They had three choices:
Let's look at all three before we do the numbers.
I can think of two scenarios where a switch to off-the-shelf software makes a lot of sense:
But it's not all skittles and beer: the Co-operative Bank in the UK found itself in a £1.5B capital deficit, partly due to a failed IT project--which itself involved (wait for it) making ridiculous customization requriements during the implementation of COTS. One example that sticks in my mind was a requirement to move the date on a report from one side of the page to another. I'm pretty sure that was critical to the bank's future success.
The clean sheet of paper. The untrampled field of snow. The promise of a fresh start. It's all there, singing its siren song: "Throw out that old crap code.! Write the perfect app, using all the latest technologies! It'll be fine!"
Maybe.
I've been around software development longer than I care to admit, and been part of more projects than I can remember. What I do remember is how many of them hit their date: darn few. Most went sideways one way or another. Some merely slewed around and ricocheted off the guardrails a bit; others went right over the cliff into the abyss. None of it was pretty and some of it was truly dreadful.
Sometimes you have no good alternative. If your app is critical to your business, has unique functionality that can't be replicated with COTS, and has the technical quality of the Model T truck in the Beverly Hillbillies, then starting over may be your best (only) option.
The benefits of a clean-sheet rewrite should be obvious: no technical debt dragged from the legacy app into the new app; you can add new features; incorporate all the newest design and coding patterns like TDD; design perfect classes, etc. And IF you can actually DO all those things you'll have a pretty awesome app. However, the downside of a rewrite should also be apparent: the risk that your project, like 70 percent of all new software development projects, will fail in some way (exceeding the budget or schedule or failing to implement user requirements); it will possibly take FOREVER; pull resources away from more important projects; and fall victim to that notorious villain called scope creep.*
Not all old code is bad code; sometimes (often, actually) it makes sense to keep the good, toss the bad, and bring everything forward. That's where migration comes in. Some scenarios:
Pros and cons of migration? On the plus side, it's faster and less expensive than rewriting (see below); you will initially wind up with a visually- and functionally-equivalent version of the legacy app so you won't need to retrain your user base; you can probably push the work down in the development hierarchy saving your top guns for the tricky new apps you want to write. Automated migration won't introduce logic bugs into the code,** so not only is the resulting app "safe" to use but you avoid having to find, track, and fix all those nasty bugs even the best developers write.
Migration lets you quickly replace a legacy app with a modern version--no retraining required. After deployment you can move to continuous improvement while you refactor, rearchitect, and add new goodies.
The major objection is you wind up with the same app only newer. You can certainly inject changes into the migration process, but that's generally not recommended. Instead, think of the migration as Phase I of a new, improved app. Your users can keep using the app--since unlike Agile you can deliver full functionality all at once--while you start refactoring and adding on to the new code base.
More taste less filling.
Let's say you're on the fence: your application has some characteristics that lend themselves to a rewrite and some to a migration. You have to present a cost analysis of both alternatives to The Decider. Let me walk you through an example you can use as a model. First some assumptions:
So where does that leave us? Let's run a hypothetical medium size project through this model:
Using our model, we get the following:
You can run your own project numbers through a calculator we've created. It lets you tweak the assumptions about productivity and costs and shows you what a rewrite vs migration will cost:
Here's a common scenario: you have an app that warrants migration, you have reasonable development skills and time available, but you don't want to do the whole project yourself. Turns out that a significant amount of the effort to complete one of these projects is validating that the new application functions identically to the original one--in essence, if a test passes on the original app the test must pass on the migrated app. We can help. Our Modernization Acceleration Program (MAP) can move your VB6 or .NET code to the new platform where we rely on you to do the last mile (QA and resulting bug fixes). We ensure that it works; you ensure that it works correctly. Sometimes we refer to this kind of project as "visual equivalence" to distinguish it from functional equivalence.
I realized today that the end of all support for Microsoft operating systems that can run 16-bit code is only 3 1/2 years away. And that's the end of extended support; unless you are willing to pay****** they really go out of support in 2018. Now that may seem like forever but these projects take time and the hackers are out there waiting for this, licking their nasty lips like hungry jackals looking at a wounded zebra.
Don't be a wounded zebra. Give us a call to discuss how you can end the risks of legacy code.
------------------------
* I once built a house that involved a lot of scope creep and every time I think of it I have to go somewhere quiet and lie down.
** Well, our's doesn't anyway. Can't guarantee somebody's else doesn't.
*** Studies show the range from 10-50. One of the best teams in the world did 10 (want to guess who?).
**** Just remember that if you do, you may have to live with your estimate.
***** Plenty of studies suggest net savings from going way offshore aren't what they're cracked up to be. Google it.
****** If you think you pay a lot now, wait till you get a quote for extended support. Gulp.