Bye Bye Legacy System
And the team handling it
Hey, fellow Leader 🚀,
I am Artur and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach me on Substack and share my newsletter if it helps you in any way.
A decommission of an IT asset is generally received with some apprehension. If the asset is a server, the team will crawl into darkness because infrastructure migrations are the work of dark elves. However, if the asset to decommission is an entire IT application, the team’s job security will be the new major ticket included in the sprint.
Big IT legacy assets are expensive to maintain and naturally have big weights during budget negotiation. If an application is becoming old and noticeably too costly to do anything with it, is a matter of time before a decommissioning project will happen. The challenge here is to have the team onboarded with such migration. This is not a simple migration of platform A to be shut down and switched to platform B. When the migration is the entire system, which is also the source of all the team’s work, the minds of everyone will be on when they will be fired.
Imagine going to a bar with friends and coworkers, and some complain about how difficult is to handle resistance to change when improving team methods. Those changes could be kids’ play when compared with the effort and challenges of motivating a team supposed to continue to work on a dying system.
Having an entire system migration is an executive decision done at multiple levels inside the organization. During the initial study, the technical advantages of the new solutions are highly important. However, it should not be the only chapter in the migration plan. The question of “What we are supposed to do with the people when the migration is over?” should be addressed from the first day. Ideally, the first people who should work on the new system are from the decommissioned system to-be.
Nevertheless, performing an entire platform reform is also an opportunity to address the team handling it. Is a way to address the “casting errors” or the engineers who are seen as too hard to deal with, or who hardly will adapt to new realities. Some decisions are made to prevent the known bad apples from working on a brand new system, only to be replaced by yet unknown recruits, racing their way into making the same mistakes done on the old system, in a brand new platform.
The ideal scenario is to have an organization that has multiple IT teams that can absorb some of the people who are working on the old system and don’t fit in the new reality. This will build an image of trust by showing that nobody will get fired if a system is decommissioned. In the long term, it provides a more stable project environment to perform the migration instead of handling increasing turnover rates which will only hurt the project. Systems are not properly migrated if the engineers working on them feel they will lose their jobs. Is also a challenge to recruit engineers for a migration project where they know the job will disappear in a few months.
If using a temporary workforce is the only way out, the alternative would be to hire consultants or freelancers to perform the migration. It’s a feasible approach but it will only skyrocket the investment cost and hurt the manager’s position to justify any overrun during the next budget review.
That’s it. If you find this post useful please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest in the comments or send me a message on Substack.
Cheers,
Artur
The fear of obsolescence, the anxiety of the unknown, the resentment towards perceived "winners" and "losers" – these are the silent saboteurs that can derail even the most meticulously planned migration.