Back to resources

Challenges of Migrating Old Legacy Software

Dev Processes
Productivity

27 June, 2020

Tim Olshansky
Tim Olshansky

Chief Product & Technology Officer at Zenput

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Managing Remotely: Balancing Team Cohesion and Focus Time

26 May

Jonathan Belcher, Engineering Manager at Curative, explains how to balance team cohesion and individual focus time, tapping into his experiences of working remotely for seven years.

Remote
Micromanagement
Meetings
Internal Communication
Productivity
Psychological Safety
Performance
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

Why You Should Take Technology Risks in Product Development

25 April

Matias Pizarro, CTO and VP of Residents at ComunidadFeliz, recalls a time in his early career when he took a technology risk that had wide-ranging benefits to his product's user experience.

Innovation / Experiment
Product
Scaling Team
Dev Processes
Matias Pizarro

Matias Pizarro

CTO and VP of Residents at ComunidadFeliz

The Necessary Structures of Time Management

14 April

Suryakant Mutnal, Engineering Manager at PayPal, discusses the importance of time management and the necessary structures in order to create internal consistency.

Goal Setting
Managing Expectations
Remote
Deadlines
Productivity
Roadmap
Prioritization
Performance
Suryakant Mutnal

Suryakant Mutnal

Engineering manager at PayPal

Why Documentation Is the Key to Success

6 April

Henning Muszynski, Head of Frontend at Doist, promotes his ideas on how documentation ensures consistency, efficiency, and standardization.

Alignment
Collaboration
Productivity
Hiring
Team Processes
Henning Muszynski

Henning Muszynski

Head of Frontend at Doist

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.