Legacy application modernization: Eeny, meeny, miny, moe

This is a story of three friends who built houses. Sooner or later this will get around to something to do with code.

One of the friends (let's call him Friend #1) was something of a klutz. He couldn't tell a framing hammer from a toilet seat. So he found a builder who showed him plans and models of finished houses. They talked about options for the kitchen, how many bathrooms, stuff like that. My friend went down to the bank, signed a bunch of papers, and not too long after that a house sprang up on his lot and he moved in.

Friend #2 was pretty wise in the world of DIY (do it yourself) but didn't have a lot of time, what with two small kiddies and a demanding job. He found a builder as well, but he and the builder agreed on some of the construction tasks that my friend could do on the weekends. That saved him some money, let him be involved more than Friend #1, and gave him the satisfaction of knowing he had contributed to building his family home. But the project took a little longer than he would have liked, since there were times when the builder had to wait on my friend to get his part done.

My third and last friend (I actually know more than 3 people--let the record reflect that) was super talented. She had worked as a trim carpenter, roofer, and other similar trades. Although she's not a licensed electrician, she knows how to pull wire and hook up switches and receptacles. She felt like she could build a house herself--and she did. She didn't do everything single-handed, but she was able to hire extra help for some of the bigger jobs (ever tried to pour concrete alone?) and a few specialty tasks she didn't feel qualified to take on. By the time she was done she had a terrific house and had saved a ton of money by doing it herself, but it took a LONG time before it was finished. When I asked her if she'd do it again, she said she wasn't sure. "If I had been earning money by working all those hours when I was building my house," she said, "it would have been cheaper to hire people to do it for me." She smiled. "But I traded time for money. Mostly I did this nights and weekends, so it was just my time. I DID think I'd be done a lot sooner than I actually was."

 So three models for home construction: do it yourself, let somebody else do it, and hybrid. All have pros and cons.

What has this got to do with code? (Told you I'd get there eventually.) Here it is: one thing we do a LOT of around here is talk to customers with legacy apps. In fact, the only people we DO talk to around here--aside from the Comcast sales rep--is people with legacy apps. And they come in three flavors, like my three friends. 

Flavor #1 has legacy code but has no internal resources to devote to a migration project (maybe there aren't any or maybe they are needed for a higher priority project). Flavor #2 has sufficient internal resources to devote to this--they are a sunk cost so doing their own migration project makes sense from their point of view. Flavor #3 is a hybrid model; for example, they might provide all the QA resources but want us to get the code migrated and compiling. 

So to provide this level of flexibility to our customers we've split our service offerings into Analysis & Planning and Migration Assistance.

Analysis and Planning

Is it true that the more you plan the better the project? Perhaps, but certainly the more you plan the less likely you are to encounter unexpected surprises. (To paraphrase Bilbo Baggins: "Nasty things, surprises.") A good plan can provide valuable insights into pitfalls and traps in your upcoming migration project. To help out, we have a planning service at the project level called a Migration Blueprint: a migration architect comes on-site for a week and reviews your source code, runs some of our analysis tools, and gives you a detailed plan for the project. In addition to metadata about the size and complexity of your project, you will get specific remediation advice on source code issues that don't map directly to .NET or HTML (depending on your desired target). At a higher level, we also offer PortfolioMAP: a consultative review of all the apps in your portfolio (or a logical slice thereof) with recommendations on which ones to put in outcome buckets like "replace with commercial off the shelf," "maintain and invest," "rewrite," and "migrate." Add to that some experience-based estimates on the resource requirements for each outcome category and you can build a multi-year budget (people, time, and money) to get out of the legacy trap.

These services are a great way for companies who are not quite sure about legacy migration to explore options with our highly-experienced staff. After billions of lines of code migrated, our technical team has seen basically every conceivable code snafu already and can help you figure out what you should do.

Migration Assistance

Once you decide migration is a better option than kicking the can down the road, or rewriting an app from scratch, you have some helpful options. Depending on your experience with migrations, skills inventory in your development and QA organizations, time and money available, you can elect to do the whole project yourself using automated migration tools (like VBUC or WebMAP) (see Friend #3 above), hire someone to do the whole project for you (see Friend #1) or a hybrid (aka Friend #2) model.

• Do it yourself: Given the resources and perhaps a bit of guidance, this is very do-able; after all, your developers wrote it and have been supporting it so they know the code, the functionality, and the internal logic and processes it represents. Automated migration tools like VBUC and/or WebMAP cut both the time required and the total effort so you can move from one platform to another quickly and efficiently. Perhaps more important, the business logic code is preserved so new defects are not introduced. Downside? You have to take those resources from other (possibly more critical) projects to do the migration. 
• Have someone else do it for you: The "hands off" approach is to find a trustworthy vendor and let them do it. Most of our larger customers (F500 enterprises) choose that option in order to keep their in-house developers focused on the highest priority projects. Our typical approach is the fixed-price project to create a migrated version that is functionally and visually equivalent to the original. When you choose a vendor for this approach, the success measure should be that the migrated application can pass the identical test suite that you use for regressions on the source application (adjusting for necessary UI differences--failing a test because something is one pixel off doesn't help anybody).
• Share the load: The hybrid model is becoming more popular with many of the people I talk to. What we usually do is take the source code, migrate it with our tools--often customizing the tool to provide a higher level of automation for that specific application-- then get it to compile. The customer can then take over the project and finish up, providing their own resources to tweak the UI into conformance, replace obsolete components with new and improved versions, and perform QA. This approach gets the bulk of the code over quickly to the new platform/language while allowing the customer to use some of their sunk-cost resources to reduce the hit on cash flow.