Challenges of Migrating Old Legacy Software

Problem

The problem of managing old legacy software troubled every single organization I’ve been fortunate or unfortunate to join. Any business that survives long enough would develop things that no longer make sense, an old thing that needs to be turned away. One of the projects that I was responsible for in my prior role was moving a legacy software application that ran on Java and was incapable of scaling horizontally to the cloud.

In order to move our old legacy software to the cloud, we had to make it small enough so it could run on hardware that was available to us in the cloud. We had to automate a large number of things that were done manually because as such they were not available to us on the cloud. Also, we had to figure out how to make this piece of software cloud-native and have all the things within it evolved and instead of running on a single server be capable of running on multiple servers of ideally a smaller size relying on services that weren't in the same data center.

On top of that, a complicating factor was that we had already partially implemented a cloud migration in the past that had been unsuccessful. The complexity of the situation was coupled with relatively aggressive deadlines and meager resources, including the lack of a sufficient number of people who would be able to do it quickly.

Actions taken

We started off with a fairly comprehensive deep dive and developed an analysis that could help us differentiate between the things that would be easy to change and those hard to change. We tried to approach things in parallel. We identified a number of more easy things -- we put together task lists and backlogs and made small, incremental changes working through that over time. Also, it was clearly stated that the team would make these changes when they could. We were able to look far forward and have a long enough roadmap to see the opportunity to get those things done. Of course, the problem was not the easy stuff, but the hard stuff.

In order to tackle the hard things we had to start with a small subset of what the system did -- we shrank it and made it as simple as possible. We identified what we considered the core of the system and tried to migrate just that piece (with no real traffic) in a proper end-to-end cloud-style deployment so that we could understand all of the workflow problems, all end-to-end challenges, and unknowns of the project. This approach resembled tracing a bullet -- we shot in areas of the least certainty so that we could identify the outline of the problem.

We hired full-time specialists who had done this before to help us with the migration. We tasked them with figuring out the unknowns of moving the old to the new but starting with only a small portion of it. The reality was that the system had been built up over time and that it started small and then grew. Trying to take the whole big thing and move it at once was going to take five and more years and was never going to be successful. Therefore we started with what we thought was the smallest part, identified the riskiest part along with a new set of easy things to work on. We continued to follow that pattern. As we increased the scope of the system that we deployed, we would uncover more of the unknowns and once we were clear on what those things were we would again put together that task list of the little things that needed to be worked through. We would prioritize that task list and we would continue to work through it. As we became more certain of what was required, it became a lot easier to advocate for the resources that were necessary.

Lessons learned

• You need to identify the riskiest things first and use that information to develop the plan of attack. Rather than having just one big goal that might take many years, break that goal down by identifying what the risky things are and put together a roadmap for each of them.
• Small constant incremental change is very effective and creates a snowball effect. When people progress, that enhances motivation which leads to more engagement and improved productivity which, again, leads to more traction and success. Taking something really hard to accomplish, breaking it down into lots of successes, became my main method for implementing changes.
• Advocating for resources when you don't know what's required and is based on guessing can perhaps get you lucky, but far more powerful approach is to advocate by having a clear plan and solid data to determine, for example, how many parallel work streams you can have, what are the independent areas that can be worked on, what is the average velocity of a ramped-up team member, etc.
• Starting with a small team, getting solid data, and then making progress and using the data to help make decisions for others is a great way to influence a change.