What we talk about when we talk about application modernization

I just finished reading a white paper from a highly-respected technology company about their definition of application modernization. Their definition of application modernization is "repackaging" legacy applications for "more agility" including some "cloud native" features.

I call bulls***t.

What exactly is application modernization? Like so many tech-born terms, people feel free to define and redefine it. But for starters, let's look at how Wikipedia defines software modernization:

Legacy modernization, or software modernization, refers to the conversion, rewriting or porting of a legacy system to a modern computer programming language, software libraries, protocols, or hardware platform. Legacy transformation aims to retain and extend the value of the legacy investment through migration to new platforms.

There are some key terms here that I think are required for any actual software modernization effort:

• Legacy system: Not just old: legacy systems are based on obsolete or unsupported languages, runtime platforms, and operating systems. IBM 360 assembly is legacy. All COBOL is legacy. Visual Basic 6 is legacy. Windows XP is legacy. Anything that depends on 16-bits is legacy. 
• Conversion, rewriting, or porting: Modernization isn't about "lift and shift." It's not about sticking old crap into a VM. It's not about hosting in Azure instead of that Dell server under Harry's desk. It's about actually changing the app.
• Modern computer programming language: This is the real nut of the problem. All applications are written in code, and anything written in an old programming language is harder and more expensive to maintain than something current. You cannot modernize a legacy application without changing the programming language. Anything short of that is just putting lipstick on a pig.
• Retain and extend the value: If you've got a legacy system, it has value. Otherwise it would already have been shut down. Legacy systems are too much trouble--too expensive to maintain--to keep running unless they deliver a lot of business value. Y2K--only 19 years ago--freaked everyone out not because of the end times predictions but because they had to touch truly ancient legacy systems, which were still running because they were so valuable. And having touched them, they are largely still out there.
• Migration to new platforms: A VM running Windows XP hosted on AWS is not a "new platform." It's a dangerous, out of support, obsolete platform, regardless of the appeal of wrapping it up in a nice container.

Legacy systems are a big bowl of wrong

Legacy is a huge problem--Gartner estimates up to 70 percent of the Global 2000 IT budget is spent on legacy application maintenance. The US government spends 80% of its IT budget on maintaining legacy systems, some of which were written when John Kennedy was president.

• Legacy systems block adoption of modern engineering practices like DevOps
• Legacy systems block ISVs from moving to a SaaS (subscription) model
• Legacy systems have inferior user experiences (UX) leading to a loss of efficiency
• Legacy systems require developers approaching or past retirement age--both rare and expensive
• Nobody wants to work on legacy systems
• Nobody wants to run legacy systems
• Legacy systems are a huge PITA.

Real application modernization isn't lift and shift

Lots of vendors--SIs, consultants, public cloud companies, virtualization and containerization companies, and possibly your Great Aunt Sadie--will try to sell you a solution to your legacy application problem that involves "lift and shift."

Think of it instead as lift and s**t.

The problem with lift and s**t is that it doesn't solve any of the root problems your legacy software is causing:

• It doesn't replace the obsolete programming language the source code is written in.
• It doesn't provide a pipeline of new less-expensive developer talent to work on it.
• It doesn't have a modern UI.
• It doesn't move an app that is captive to the desktop to the web.
• It doesn't improve integration with other systems.
• It doesn't allow for DevOps.

Lift and shift is just sweeping the problem under the carpet.

Application modernization requires modern programming languages

Abraham Lincoln once asked, "If you call a tail a leg, how many legs does a dog have?" Upon being told "Five," Lincoln replied, "The answer is four. Calling a tail a leg doesn't make it a leg."

Calling a VB6 app "modernized" because it's running on a VM doesn't make it modernized, regardless of what people tell you. If the source code is VB6, there is literally nothing you can do to make it modern without replacing the VB6 source code with something contemporary. It could be C#, or VB.NET, or even Java or JavaScript, but it cannot remain written in VB6 and be called "modernized."

The same thing can be true for and Delphi and PowerBuilder and Informix. In the web world it's ASP Classic or ASP.Net with web forms. You get the picture.

Painting an old car doesn't make it new again

If you put a beautiful, 12-coat, hand-rubbed paint job on a 1967 Ford Mustang, it's still an old car. It may look good, but it's not a modern car. It doesn't have disk brakes. It doesn't have ABS. It doesn't have fuel injection. It doesn't have air bags and shoulder belts and crush zones and all the rest of the things that keep you safe. The things that make it reliable. The things that make it economical.

In short, there's nothing you can do to a 1967 Mustang to make it as good as a 2019 Mustang.

You can put a VB6 application in a virtual machine and think that you've modernized it, but you haven't. You still have an antique application. It's hard to maintain because the language is no longer taught in schools and young developers don't want to sully their hands working on it. The developers who will are either past retirement age or almost there; they are rare and expensive and know it. After they retire they will offer to work on your code as consultants for 3X the hourly rate you used to pay them. And you'll be happy to get them. The UI of your app looks exactly like what it is: something designed in the 1990s. The runtime and libraries it uses were not designed with 2019-levels of understanding of and experience with the last 20 years of app security improvements. Automatic updates to Windows operating systems might cause one of the application dependencies to stop working over night, bringing your app to a complete standstill.

The brain is good but the body is bad

If you've read this far you're either a masochist or you've got one of these apps and it's still delivering value so you can't kill it. 

But you don't want to keep it like it is.

The business value is there, encapsulated in the business logic and rules codified in the source code. It works, because over the years it's been in production, the bugs have been found and fixed. Sure, the code may look pretty horrible after so many surgeries, but it works. If it didn't work, you would have discarded or replaced it long ago.

The brain, in other words, is good.

The body, on the other hand, is shot. Old language, old libraries, old components, old runtime. And it's the body you have to keep working on. 

What you need is a brain transplant.

Real modernizing replaces old bits with new ones

Most people will tell you the only real solution to obsolete legacy apps is a ground-up rewrite. Start with a clean sheet of paper and party on! Write that perfectly designed and coded application like you always wanted to. Use perfectly designed classes, write all the tests first and then the code to implement them, create UML diagrams and perfectly commented methods. There will be no bugs, the users will sing your praises, and developers far and wide will bow down at your magnificence as you walk past: the greatest programmer to ever live!

Right.

If you've ever written any raw code longer than hello world, you know that's a bunch of nonsense. In a perfect world you might do perfect work, but it will take forever. And this is not a perfect world. Your bosses want it yesterday. The users keep changing their story. No one is sure which other systems you have to integrate with, so better integrate with all of them. Let's use Angular JS, no Angular Not JS, no React, no, let's change it again. And by the way, we still need to keep the legacy system up to date, so just squeeze that in, ok?

Recently I sat in a customer's conference room and the head of development told me--after rewriting a key application already twice over a 20 year period--they would do almost anything to avoid rewriting it again. They knew from experience just how difficult writing new code is. They knew how long it would take and how hard it is to manage schedule and resources. For them--like many others--automation migration was a life-saver.

There's a reason we hear from similar customers who started down the rewrite path and gave up. It's hard, it's risky, it takes forever, it never seems to get done. Migration with tools like VBUC or WebMAP, however, get that working business logic (the brain) into a new body (C#, Angular, Java Spring, VB.NET, TypeScript, etc) quickly and efficiently. The code is modern, the platform is current, the language is familiar to both your current dev team and new hires right out of school. The guts of the application have been replaced without blowing the budget or the schedule. 

 So when you hear promises from companies about legacy application modernization that involves "packaging" or "containers" or "virtualization" you should ask yourself do you want to shift the problem or solve it?  Cling to the past or embrace the future? Because if you've still got VB6 or PowerBuilder or Delphi you're not talking about app modernization.