login


Google Sign inLinkedIn Sign in

Don't have an account? 

Challenges of Migrating Old Legacy Software

Dev Processes
Productivity

27 June, 2020

Tim Olshansky, EVP of Engineering at Zenput, explains all the challenges of migrating legacy software to the cloud emphasizing the importance of identifying the riskiest things first and applying small, incremental changes.

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.

Related stories

What We Learned From Running Open Spaces
30 June

Jeff Foster, Head of Product Engineering, highlights key learnings from his experience of running open spaces and if and how it contributed to an increase in innovation.

Company Culture
Productivity
Impact
Jeff Foster

Jeff Foster

Head of Product Engineering at Redgate

Some Ideas for Breaking Down Silos In Your Organization
30 June

Jeff Foster, Head of Product Engineering, shares how he managed to break down silos in his organization by encouraging their employees to choose their own team.

Team reaction
Managing Expectations
Company Culture
Internal Communication
Collaboration
Productivity
Reorganization
Jeff Foster

Jeff Foster

Head of Product Engineering at Redgate

Some Useful Tips for Decoupling Releases and Deployments
30 June

Pierre Bergamin, VP of Engineering at Assignar, outlines some useful tips for decoupling releases from deployment and increasing deployments by a huge factor, speeding up reverts and planning releases in a better way.

Agile / Scrum
Dev Processes
Pierre Bergamin

Pierre Bergamin

VP of Engineering at Assignar

How to Identify Root Cause of an Application Failure
30 June

Murali Bala, Director, Software Engineering at Capital One, outlines how he applied a root cause analysis to fix a recurring outage of their website.

Dev Processes
Leadership
Productivity
Murali Bala

Murali Bala

Director, Software Engineering at Capital One

Challenges of Migrating Old Legacy Software
27 June

Tim Olshansky, EVP of Engineering at Zenput, explains all the challenges of migrating legacy software to the cloud emphasizing the importance of identifying the riskiest things first and applying small, incremental changes.

Dev Processes
Productivity
Tim Olshansky

Tim Olshansky

EVP Engineering at Zenput

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.