What to Do When Replacing a Legacy System
Content
These tend to be programs that companies started using many years ago, and these programs were stuck before the “industrial revolution”.
Companies may decide to keep a legacy system for various reasons, but there may also be a situation where a company takes the time and money to redesign its internal IT architecture and get rid of that outdated system. Together, let’s take a look at how to do this.
Picture of the Entire IT Infrastructure?
To successfully eliminate a legacy system from your company, you need to know what role it plays in the entire IT puzzle. What are the dependencies within the internal systems? How much is the legacy system being used with respect to its capabilities and features?
Another question to answer when looking at the current state is the future state of the architecture. It will make a difference whether you keep your architecture and just get rid of the legacy system, or whether you redesign the entire architecture and use a different type of infrastructure (for example, you are running on a public cloud and want to move away from a global provider and choose a local cloud option or a hybrid cloud for example – see our article on cloud repatriation for more details).
Evaluating the Legacy System
Taking a thorough look at the legacy system itself is also an important step. You’re using it for a reason, but is that all it can do? What are its features and capabilities? What do you actually need from its characteristics? Can you use another system you already use to take over the activities of the legacy system?
One possibility is that you may find that you only use a certain part of the legacy system, and you don’t need other modules. Such an activity could then possibly be taken over by another, already implemented, system, or you could find simple software that focuses purely on such an activity.
However, it may happen that a legacy system takes on more than one activity, and on top of that it is a combination of different kinds of activities. In that case, the decision is harder and your analysis of the current architecture will have to include options to cover the traffic with current systems.
Whatever the role of the legacy system in your business, a thorough analysis is in order. Without it, you may end up decommissioning something you have no way to continue operating. This can create a problem in the form of an internal IT outage, for example. Increasingly these days, that means crippling the entire company’s operations.
Plan for a New Architecture
So now we know where we are and what we need to move forward with. So the next step is to move forward – a new architecture plan. The complexity of this will depend on whether you are changing the architecture overall and how hooked the legacy system is in your IT architecture and operations.
So a new architecture analysis will land on your desk, and the next component should be a project plan for the entire change. It is not advisable to save time on such steps, because if something is not well planned, then it will surely manifest itself and at the most inopportune time under the least appropriate conditions.
Team selection
We have now turned our attention to the technical parts of the change. It’s just that in IT it’s not about the machines, or the plans, or the architecture. Everything is always about people. And a change such as moving away from a legacy system will require a carefully prepared and well-chosen team.
Be sure to include your IT people, especially those who are in charge of the infrastructure and also in charge of the legacy system. If the legacy system has been custom developed for your company and there is a possibility that it can be converted into a service, then you will also need to have programmers on hand who can drill down to the bones of the system.
And then you also need to have infrastructure type experts on hand who can find the right architecture that fits like a glove. And this is where you may need to reach out to external resources (outsourcing is no exception in such cases – both in highly technical areas and in project management, for example).
Where to Start?
As always – with a consultation. The right partner with the right wide-ranging know-how will not only help you properly analyze the current state and find a way to replace the legacy system. But it will also help you think about what you actually require from IT, what your needs are and how the right choice of architecture can cover them.
