Migrating technology

I've been thinking a lot about extending the life of a software system.   There are several hard problems to solve.  The first problem I want to discuss is migrating to a new technology stack.  I'm skipping the discussions that take place before the decision to transition to a different technical stack are made.  Whether that decision is good or bad, if it has been made it is your job to get it done.

Consideration #0 - Don't do it all at once

Big rewrites are very likely to fail. So don't try them.  Learn from our collective Agile experience and establish a backlog for your migration.  You will learn a lot from planning the backlog, such as business and sales pain points, architecture dependencies, and areas that don't require immediate attention.  This gives you the advantage of putting new technology into the market faster, further accelerating your learning feedback cycle.

Consideration #1 - Build new features in the new technical stack

While straightforward to understand, this is perhaps the most difficult to implement.  Your end user work flows have to be (relatively) seamless.  The existing system was designed to support a collection of end user goals and workflows.  If the new feature is presented is a jarring manner, you risk putting your users off.

A few years back, my team was challenged to move from Delphi to .NET.  We found ways to render .NET screens inside Delphi containers.  Although we used different component libraries, an end user had to be extremely astute to notice subtle control rendering variations.  A more recent experience involving more disparate technologies has required some visual redesign of the existing application to reduce the perception gap.

Regardless of your technologies, you have to make the user experience transition as seamless as possible.  

Consideration #2 - Rewrite parts of the existing system when appropriate

As your existing system requires modifications, determine if the feature to modify is a good candidate for being rewritten.  Again going back a few years, we were faced with a major overhaul to government reimbursement for Home Health services.

Instead of modifying the existing (tried and true Delphi) payment system, we left it alone.  We wrote the new billing engine in .NET.  This allowed us to guarantee no regression to existing billing and to add significant capability in the new system.

Consideration #3 - Accept that some stuff will remain around for a very long time, maybe forever

This can be hard to accept.  Engineering, and I suppose business, is about choices.  Those choices involve what you do and what you don't do.  There are parts of your system that work, are reliable, and aren't causing you lost sales.  Before you rewrite those pieces, have a compelling reason to do so.

In general, your goal is to devise a scheme to migrate to the new technology over a reasonable period of time, incrementally, with little impact to your end users.  I know this is hard.  But it is possible.  The alternative - a massive all-or-nothing rewrite - has proven again and again to lead to failure.