Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

Challenges of Migrating Old Legacy Software

Dev Processes
Productivity

27 June, 2020

Tim Olshansky
Tim Olshansky

EVP Product & Engineering 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

The Right Way to Ship Features in a Startup

11 November

Matt Anger, Senior Staff Engineer at DoorDash, shares how he took the risk and shipped features in a startup.

Alignment
Product
Dev Processes
Matt Anger

Matt Anger

Senior Staff Engineer at DoorDash

The Problem-Solving Process: A Modern, Data-Driven Approach for Engineering leaders

28 October

Sudheer Bandaru, CEO at Insightly Analytics, recalls how he formed a company for carrying out data-driven solutions to daily engineering problems.

Dev Processes
Team Processes
Sudheer Bandaru

Sudheer Bandaru

CEO at Insightly Analytics

Creating an Engineering Vision

25 October

Mustafa Furniturewala, VP of Engineering, uncovers how he created a succinct engineering vision with their company's values in mind.

Alignment
Mission / Vision / Charter
Goal Setting
Productivity
Mustafa Furniturewala

Mustafa Furniturewala

VP Of Engineering at Coursera

Taking The Lead As A Manager In Crisis

14 October

James Tobias, Senior Product Manager at Mapware, unveils a riveting journey to build a product from ground zero successfully.

Product Team
Product
Dev Processes
James Tobias

James Tobias

Senior Product Manager at Mapware

Strategic Ways to Stop Losing Customers

13 October

Mary Fisher, Software Engineering Manager at DrChrono, shares how diligently she worked with teams within her organization to retain customers.

Alignment
Innovation / Experiment
Product
Dev Processes
Convincing
Tech Debt
Prioritization
Mary Fisher

Mary Fisher

Software Engineering Manager at DrChrono

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.