How to deal with legacy systems/solution 

Chances are that at some point, regardless of situation, a solution will either be upgraded, changed, decommissioned or a migration will occur.

A significant amount of my career revolves around dealing with issues, problems, challenges or whatever skeletons we find in the closet, associated with the system/solution in question.

Sadly, if you are looking for an article that promises a magic bullet to fix all of the issues that you might encounter…. Well, I’ve been searching for quite some time and haven’t found any. At first I was frustrated with the futility of not having a one size fits all solution that can be applied to every legacy system, but later on experience teaches us that there are multiple factors that can influence how we deal with legacy.

In this article we will dissect the different components involved in a solution, that will help us identify the lifelines tied to the solution, enabling us to produce smaller chunks of workload and work in an agile manner. 

Next we will try to expose all of the involved components and how they can impact a solution and see what challenges lie ahead when it is being flagged as legacy.

The component list:

1. Business
2. Financial
3. Technical
4. Users
5. Migration/transition
6. Challenges
7. Conclusions

While going through this article, a significant amount of assumptions are made. Therefore, if it doesn’t overlap completely, then some aspects might deliver insight that maybe wasn’t available before. Others are common sense, but along the way I’ve learned to not make any assumptions and diligently go through all of the points required. 

1. Business:

We will start of with the Business requirements:

I’ve rarely seen actions done without a reason and when it comes to business, it definitely is no exception. A solution is selected to cover certain needs. These are not selected at random, but are requirements that help a business grow, develop, expand the customer profile, automate, stay updated and competitive etc. The reasons mainly vary and are associated with the business profile. Therefore some entities might consider certain aspects with a high degree of impact as opposed to others. But there is one common takeaway: “We need something else, this solution is becoming a problem”. Whatever the reason, the bottom line will almost always be the same.

It is of great value to be able to transparently convey the reason to all of the involved parties. In some cases, it might not look like a good idea, or it will be challenged: “If it is not broke, don’t fix it.” or “We can’t afford a new solution, this one has server us ok for the past 10 years.” Whatever the reason, get everyone on board as much as possible. Some decisions might not expose their advantage as clearly as expected. A common example is if a company wants to become a partner of a certain vendor. A strong point of negotiation is to assure exclusivity in one's organization, stating that everyone in company A will use software B for accounting purposes. Looking at a starting point, where everyone is using different software from different vendors or their in house flavor, it becomes quite impossible to state the expenses associated with accounting. Sure, solutions can be built to compensate for this aspect, but at the end the question stands if it’s worth it.

One painfully obvious reason, that a lot of people tend to neglect, is that we work for money. Even non profit organizations need liquidity for their operations. For profit entities, well… that’s their main goal. Also these decisions assure that all of us have a stable pay at the end of the month.

Having this topic warmed up, let’s jump into it.

2. Financial

For most of us, excluding the financial department, money isn’t too much of a concern in an organization. As long as you are not involved in calculating prices for a service/solution or whatever billable product your organization produces, then it’s just something that is…  there.
Since I’ve started off as a system administrator, which by heart I will always remain, I’ve noticed that very few people take into account how much a feature costs and what it’s return is. For me it was important that whatever solution or system is used, it should better make my life easier. It was of little importance to me if it was associated with a monthly bill of 100€ or 1000€.

It is well known that if you let loose an IT department's expense limit, it’s the equivalent of a 7 year old child in a candy store. But it’s something to empathize with. All of us want to purchase in our daily lives whatever is available to us, that improves comfort and is easy to use. Similar to our daily lives though, we purchase whatever is available in our budget. Same here. There is little difference.
Therefore financial usually looks at how a solution change is affecting the overall cost. Will production be cheaper, will efforts be reduced. When will we absorb the cost of the migration? Will the transition period end up costing us more that we hope to gain? All these questions are commonly reflected in the Return of Investment, ROI for short. In very few words, if this index makes your financial team happy, then there will be little resistance from their part.

3. Technical:

At the end of the day, the people that are most exposed are the people that are working to maintain the solution. Often the unsung heroes behind the scene, that make sure that every part of the consumer experience is close to advertised, every escalation or incident that arises, is mainly fixed by whoever is keeping the lights on.
There is a funny paradox when it comes to technical aspects of a solution:

If it works perfectly - “ Why am I paying you for?! You're just sitting around.”

If it doesn’t work perfectly - “Why am I paying you for?! You’re just sitting around.”
As oblivious as the majority is in regards to the financial implications, it is similar to what effort is associated with actions behind the scene.

Operations are a solutions lifeline and the developers main feedback source.
For whatever crazy workaround you see implemented for whatever issue was reported, operations are going to pull it through. Sadly, this doesn’t come without a cost. The tendency of workarounds or temporary solutions to become permanent fixes is very high. That’s how skeletons get in the closet and we will make inventory of them when the solution becomes legacy.

But let’s move on to the people that have to be accommodated, the users.

4. Users:

Every solution, either directly or indirectly, has it’s target audience, the users. Even if the solution in question is a component of a broader offering, the chances are high that it will influence either the user experience, gather data of that user, or indirectly determine how to exploit the users behavior. 

The consumption of a solution is strongly associated with users, since in the end users are the main revenue source. Even applications that don’t seem to be directly tied to a user, they inevitably are associated with a consumer market, which in my opinion are users with extra steps.

Therefore the user's needs need to be met. Happy users are recurring users and the main scope when handling users is to keep them involved and interested in the solution that they are consuming. Every solution needs to have multiple lifelines to gather user feedback that drives development and improvement.

Nevertheless at some point the solution becomes legacy and then our next topic comes into play: Migration and transitioning.

5. Migration and transitioning:

Business needs don’t disappear, they either stay there, being core business needs or they are changing to stay updated to current trends and adapt to new needs due to an evolving market. One of the main reasons why a solution becomes legacy and a transition period comes along, where the legacy solution and the new one co-exist during the migration.

The longer the migration, the harder the transition. Establishing when what happens and how to switch over from different components is key to a successful migration. The best migration is when the end user has no idea that they were migrated. Of course, this applies only to backend solutions, where changes aren’t visible to the consumer. 

When moving from one vendor to another or a totally different solution, that has little in common with the legacy one, compatibility will become a challenge. Any compatibility issues reflect in how a user experiences the transition. Not all transitions will run smoothly. Remember the skeletons in the closet? Here is where they will show their ugly faces again and sabotage your efforts in ways you can’t imagine. As a result stress resilience and a capability to adapt will be the best tools in your toolbelt. 

The success of the migration is directly related to the amount of knowledge that is present with both solutions, to be able to translate functionalities and predict how changes will manifest in production. Test environments are nice, but usually there are huge differences between production and test environments. The first major difference are the users which produce different behaviors.

At this point communication during the migration is a must have item. You will have to reach out to them, they will be annoyed about it, but in the end everyone involved needs a certain level of awareness about communication in regards to a transition. Looking at it from a more familiar example, imagine that someone comes along and changes your kitchen without telling you anything about it. The next morning, you wake up and want to make a cup of coffee to start the day. But where is the coffee machine? Where is the coffee? Where did your favorite coffee mug end up? You just see a note: “Your kitchen has been updated. Enjoy.”

Definitely my day would be ruined, since everything I had planned for that day… got delayed or canceled until I can figure out how to use my new kitchen.

Same goes for solutions as well. During this phase, users will mainly complain if they have to adapt to a new consumption behavior. Budget time for requests to clarify how to do actions in the new solution as opposed to the legacy ones. Creating small instructions that can translate actions in the previous solution to the new one, will come in handy. A supporting community, if possible, is golden. No one person can predict all of the actions needed by the end user, but themselves. Work together with them to help smooth over the transition.

Pointing out a few of the issues that can occur, we can step into our last topic, challenges.

6.  Challenges:

Remember those skeletons? Well, when it comes to legacy solutions, you will find them all. Some can be addressed, some will be solved with the transitioning to the new solutions, others will haunt you for as long as you will perform the migration. There is no amount of planning that will cover them all. That means you will have to make a considerable amount of calls when it comes to what should be addressed, what is worth pursuing and what not. Don’t attempt to fix everything, it’s just not worth it. But how you end up handling them is going to be key. Also important on this note, is to learn to share the burden. It is true that there should be someone who keeps a birds eye view, but you don’t have to carry the load alone… well, except if you want to or if you can.
Management will most likely be on edge during this transition. Communication with them is equally important as communication with the users that will be affected by this transition. If the communication is lacking, they will follow up on it… since that’s their job, so don’t be surprised. Having healthy communication with management means that you can focus on the actions that you have planned in an already complicated situation. Continuous requests for a status update can be a distraction, so get in sync on what makes the most sense for both involved parties. There is no magic ratio here, so you will have to figure it out by openly communicating with management.

During migration efforts, the term “timeline” is loosely defined. Those skeletons are time consumers, deadline pushers and massive delay generators to whatever you had planned. Keep an open communication with your project manager, since they will have to report on it anyway.
Remember, everyone wants to know what’s going on, for how long and in the end how much it will end up costing. Keeping these topics in mind all the way, will help you deal with legacy solutions and services.

7. Conclusions:

We attempted to explode all of the involved components that are associated with a solution. Surely there are some aspects that were missed, but I tried to keep it as vague as possible, so that we can address the common denominators of legacy solutions.
As long as you manage to identify and keep track of the business needs, the financial impact of the solution, the impact of the change both on the company and the users and lastly keep an open communication with all stakeholders, you should be fine.

Don’t be frustrated if your timetable will shift. There are chances that you will end up adjusting it several times.