A brief guide to replacing legacy software

We are in a transformation process. OTTO is constantly reinventing itself and has embedded change in its DNA. As a company with a long business tradition, OTTO naturally has systems that have been with us for a long time. Our Digital Asset Management (DAM) system was originally purchased for catalogue production: it helps to centrally manage and locate content. Today, this system needs to manage millions of content items, scale rapidly, respond very quickly – and of course deliver the right results. In short, it should help us to establish OTTO as a platform. But how well can this work with a system that has been around since the ‘nineties?

To begin with, all we had to work with was a list with a handful of terms. But that didn't put us off, quite the opposite – we were motivated to solve the mystery. Because behind every term was the intriguing question: “What happens when we switch it off….?”

Over the years, many different people have contributed to our legacy system. Accordingly, it was difficult to find just one person who knew all the interrelations.

Precisely for this reason, it’s important in a process like this to first understand which specific dependencies exist, and why. It’s equally important to sharpen the scope and clarify exactly where the boundaries are.

To do this successfully it helps to define criteria that make the risk more tangible. For example, these criteria have helped us to gain clarity on:

• Types of dependency – e.g. is it a specialist or technical process?
• Data on traffic volumes
• Contact people
• Functions applied
• Direct or indirect dependency
• Degree of encapsulation.

After the discovery phase, the list of dependencies had grown considerably to almost 100 entries. The good thing was, we already had a strategy to tackle almost all of these.

In addition, Sharedien was purchased as a new digital asset management system. Its smart, native functions for the flexible management, maintenance and organisation of digital content make it very convenient for us to implement business cases. So we had to (!) integrate common elements into the existing system landscape and to draw up a detailed transformation plan. However, that would have made the transition from old to new very cumbersome.

So our task was not only to take the old system off the network as smoothly as possible, but also to transfer all relevant processes to the new system environment. To do this we expanded the core and began working together in three distributed remote teams to replace the old DAM.

Nevertheless, we found that not all information was interpreted correctly. This led to support requests, which we handled with patience and understanding. If there was still a genuine need for a change in the system, though, we implemented this at short notice.

In the end, the legacy system sailed smoothly into the sunset, towing in the new system behind it. There was no big bang; the replacement flowed quietly and progressively. Almost unnoticed, the new system is now in place and working to support our future – until its own turn to go eventually comes around.