Application modernization: lift and shift or rewire?

As it happens we talk to a LOT of people who want to modernize their legacy client/server apps.

So we get a certain amount of unscientific survey data about what people are doing, what they would like to do, and how they think they should do it.

Unscientific because there's no formal process; we don't log the data in Excel and run a bunch of statistical functions on it. We just get a feel for what's going on.

Fact: there's still a ton of legacy code running. 

Fact: people want to move it to something newer: .NET, the Cloud, a mobile device. Maybe all three.

Fact: most of the legacy code is not ideal--kind of like the uncle everyone avoids at Thanksgiving--old, wrinkled, and smells like the dumpster behind Safeway. But since this same uncle usually pops for $50 whenever your kids have a birthday he's still useful.

You can't turn your uncle into George Clooney but you CAN modernize your VB or PowerBuilder or Informix or what-have-you code into something new and shiny. You can get it so the data is in the cloud; the UX is touch-friendly; the code is in C#, Javascript, HTML5. Coolness.

The question is: how?

Here's where the primary dilemma comes in. Two fundamental approaches to the problem:

1. Lift and shift
2. Rewire with the lights on

Lift and shift

The lift and shift strategy is one focused on hitting milestones and budget and minimizing collateral damage. With L&S you move the existing functionality of the app to the new platform changing as little as possible. You wind up with your smelly uncle in a new suit. Changes are limited to those elements that just don't work on the new platform. For example, you have a VB legacy app with 3rd party controls that don't exist on .NET 4.0. So you replace them with a native .NET service and adjust accordingly. Or an equivalent new 3rd party component. Something. But you don't try to write the functionality yourself from scratch. That hideous UI? Leave it, just switch it to WPF. That new report everyone wants? Leave it out for now.

There's a method to this madness, but before we explain why let's look at the other approach.

Rewire with the lights on

You know you want to make it better. You know there's missing functionality, sub-optimal code, clunky UX. If we're going to port it, why not do it right? So you make up a list of changes, figure out the requirements for the delta, start writing code. The new app will be a combination of old and new. You're going to buy your uncle a  new suit, but also a haircut and a nose job.

This seems like the obvious choice. Which is exactly why it's the wrong choice.

Don't crush that dwarf, hand me the pliers!*

Spoiler alert: Uncle Larry doesn't get the nose job. Not yet anyway. 

See, I think lift and shift is the way to go. 

The unobvious beauty of lift & shift is that you don't have feature creep. No fuzzy requirements. No squishy specs. You just replumb an existing application to the new platform. The spec is the existing product. The acceptance criterium is that it does exactly what the existing application does. That makes it easy to plan, easy to estimate, easy to know when you're done.

Now that it's rebuilt with new innards, it's a lot easier to improve, update, modify, jazz up. You've separated the issues of replumbing from the issues of new functionality, new UX, new form factors. And you've separated the project into phase 1 = grunt work; phase 2 = coolness. And there's no reason the two phases can't have some overlap to get to the end zone a little quicker.

One central beauty of L&S is role granularity. Code conversion is hard but it's not necessarily complex. It even lends itself to automation. Refactoring a UX from a desktop to a phone is complex and possibly hard. For example, a monothlic app might need to be decomposed into applets focused on very narrow use cases, to avoid a kind of Formzilla on a 5 inch screen. Something requiring high pixel precision (mouse and keyboard stuff) needs some thought before it will effectively translate to a fat-finger touch interface. Taking advantage of accelerometers, GPS, Bluetooth, and NFC are all new and possibly interesting.

Our data shows that the L&S model gets IT to a modernized app faster, cheaper, and more predictably than the rewire in situ model. What's been your experience? 

*This has nothing to do with the subject of this blog, but I confess I was temporarily overcome with nostalgia.