Comparing the cost of migrating to rewriting

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:

1. Replace it with some commercial off-the-shelf software (COTS). Which requires customization. Which gets expensive. And all too frequently once you're waist deep in the project you find out some things the new platform can't do--things you really really need it to do. Oops. Now you're hosed.
2. Rewrite it from scratch. I think from personal experience this is the option most people consider first. In many cases this is the only good approach; in many others it's a disaster. More on this later.
3. Migrate it. Migration uses automation to quickly replace legacy code with something current; additionally you may or may not get the app refactored and cleaned up. 

Let's look at all three before we do the numbers.

The case for COTS

I can think of two scenarios where a switch to off-the-shelf software makes a lot of sense:

• Your app is a point solution to a problem generic enough that now there are ISVs with commercial software that does your app one better. Example: you have home-grown bug tracking software from DOS days; you can dump it and use Team Foundation Server or Jira. 
• Your app surrounds some core database like finance or customers; in this case building out a customizable offering like SAP or Salesforce can make 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 case for rewrite

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.*

The case for migration

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:

• You have unique business processes, algorithms, or trade secrets reliably coded in your app
• Your app aggregates functions across organizational divisions, providing a 360 degree view that would be difficult to replicate
• Your code is debugged and robust, but the language it is written in, or the platform it depends on, is obsolete
• Your app depends on external components that are no longer supported (eg 16-bit ocxs)
• Your app is fine; you just can't find developers any more who know the language and platform.

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.

Migration vs. rewrite bake-off

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:

1. Nobody actually "rewrites" an old app from scratch. Instead they write a new app to satisfy the same business problem but with new requirements, features, capabilities, etc. Like if it were an old barn you decided to tear down, you wouldn't replace it with the exact same barn: you'd build a nicer barn (concrete floor, color-balanced lights, robotic cow massagers). 
2. The AARP card-carrying grey-beards who maintain your original legacy app are not the same folks who will be needed to write the new version. The actual developers you need are expensive; let's say around $150k per year fully burdened in the US or western Europe (EU). 
3. Those same hot devs? They're still going to write between 10 and 50 bugs per KLOC (1000 lines of code). 
4. Although measuring developer productivity by KLOC/day is a terrible way to do it, it's better than other ways and it's one we're familiar with since we have accumulated two decades worth of data.
5. That said, for green-field development, total LOC / total time of project /# devs will equal around 20*** LOC per developer-day. That's partially due to coding being only about 30 percent of total project workload. Maybe your devs are better; double it if you want.**** 
6. If you WERE to just rewrite the same app (see #1 above) you'd probably cut the total cost by half.
7. If you WERE to just rewrite the same app (see #1) above and use cheap offshore resources, you could cut it by another half. 
8. Net of all the above gives you rough numbers to wit:
   1. $30/LOC  to write from scratch in US or EU
   2. $15/LOC rewrite only (no new functions) in US or EU
   3. $7.50/LOC rewrite offshore.*****

Show me the money

So where does that leave us? Let's run a hypothetical medium size project through this model:

• 50 - 250KLOC
• 50 - 200 screens (forms)
• 20 - 50 components (ocx, dll, etc)

Using our model, we get the following:

• $1.5M to $7.5M for green-field new app (US or EU devs)
• $750k to $3.75M for rewrite only (US or EU devs)
• $375k to $1.875M for offshore rewrite only (India or Ukraine devs)
• $75k to $375k for automated migration (turnkey, functionally and visually equivalent) 

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:

It's not all or nothing

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. 

40 months and counting

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.