Dealing with legacy software during a digital overhaul

Columnist and manufacturing engineer Andrei Lucian Rosca explains how legacy software and systems are important pieces of the digital transformation puzzle.

The big dilemma everyone faces when overhauling digital platforms is what should the business do with legacy software? In this context, the word “legacy” represents outdated tools, software or hardware that are still being used by companies and are still vital for operations. Their age and outdated nature pose various problems, such as high maintenance costs, security vulnerabilities and integration issues, but they can be integral to the day-to-day operations of a company.

Throughout my career, I have had exposure to several types of legacy software in different companies and industries. Organizations deal with the idea of transforming to a digital platform in one of three ways: they view the legacy software as crucial and must be integrated (high resistance), they keep using it in parallel to a digital approach regardless of the high cost, or they transition completely to a digital system, which is surprisingly the least common approach.

During my time working for a global automotive company, I encountered a semi-collaborative approach to data sharing and working together. The main problem for engineering was working together in a private ecosystem. This was caused by several factors— different rules and regulations at each location, legacy software and a legacy mentality driven by several acquisitions that were never fully integrated. Our north star became the migration to a digital platform that bridged the divide and got the locations to work together. This approach was ultimately successful, and members of the organization could easily work on their projects from any location.


 Of course, issues appeared with the transition to a digital thread, including numbering schemes and streamlining or adapting processes to local needs. I learned that it is very easy to fall down the rabbit hole if you entertain every little detail. Instead, your main drive should always be to the agreed scope. During this transition, I had to quell a lot of debates on minor things that could have derailed the scope of our projects, and there were a lot of projects in the initial phase, such as our desired outcomes from moving to a complete digital thread, which software to migrate or discontinue, vendor selection and many others.

Indeed, it’s worth taking time at the beginning to design your solution as thoroughly as possible—it saves a lot of headaches down the road and most importantly, saves money. The role of an engineer in this specific spot is to balance out the budget with features. First and foremost, in this role you must bridge the divide between design and manufacturing, this was one of the first things that I learned as I was cutting my teeth in my first engineering job. You can design a product or a solution as neat as possible, but at the end you must produce it and to produce a product is a whole other beast than just drawing it on your computer. Understanding both the design component and having a surface understanding of how the product is manufactured gave me enough credit with the shopfloor people that I became the go to person for the head of manufacturing to present their topics and work with them to be able to incorporate them in the implementation process.

One of the most important but frequently ignored topics is user acceptance. People who are working with a specific software are usually SME (subject matter experts) and know the software in detail. Because of this, it can be tough to gain buy-in, but they are your most important asset in a legacy software to digital thread transformation. They have depth of knowledge that is critical to a successful migration or transition. Who knows LS outputs? Who knows how the processes were designed? Who knows which person down the process needs to be informed? The subject matter expert will make your life a thousandfold easier, so include them as early as possible, align on scope and have them help you build it.

If I were to choose one thing to avoid at all costs during a digital transformation, it would be ignoring parts of the organization. My success in this project was a result of the frequent consultation with the people handling day-to-day business of the organization. Since we started with several locations during ramp up, we ended up working very closely with people from all over the production process. This resulted in rapid feedback on anything that we did—especially on what we did wrong. That feedback is crucial, as we could incorporate it and adapt from sprint to sprint.

Legacy software is still present in many companies, but it should not be seen as malign pieces of a process that would kill a project before it starts. Rather, it was an important piece of the puzzle that fit the organization at a specific time in its existence, and as organizations mature and digital becomes the new norm, legacy software should be considered an important aspect of a migration scenario, even if it will ultimately be replaced.

Andrei Lucian Rosca is an engineer with a bachelor’s in mechanical engineering focusing on CAD software with more than 10 years of experience in Digital Transformation projects in several industries, from automotive to consumer goods. I am currently exploring innovative solutions (e.g. IoT, AI) and how to include them in future projects.