When talking about migrating legacy systems with clients, there are many common questions everyone has. What is the most time consuming phase, what is the most difficult part of a migrating legacy systems, what are the differences between environments, etc. But there is one type of question I never hear, and it is about a very important factor. The human factor.
Why the human factor? Because the most successful migrations I have been part of are the ones where the whole team was interested in the successful migration of their Legacy System. Why would they not be?
When a migration approach is selected, it’s normally decided at a high level, and then the rest of the team starts getting involved: legacy system managers, business analysts, project leaders, and at the very end, the developers.
This causes what I call the fear of change. Having been involved in a migration project as a client when I was a young developer, I too was afraid of the change. Going to a new environment, new software and new tools scares many team members, especially when they have spent several years learning the tools they use today. The question of how to relearn something they already know how to do on a new environment is one of many concerns shared by the developers who will be charged with maintaining the migrated system.
Probably their biggest concern is whether they will still be relevant or needed after their systems have been deployed to a cloud or on-premises open-systems environment. The fact is these developers are critical to the success and future of migrated legacy applications. New developers may have more experience with modern tools and technology, but they lack the years of unique business process, application expertise, and institutional value that existing developers possess.
That’s why I think the human factor is very important. We need to involve the whole team from the very beginning. Talk to them about their concerns, training, support, and—very important—the goals, and how valuable they are to the future of the business. A team that is fearful and uninformed will not be committed to the success of a migration project and may react in ways that will cause delays and create roadblocks that can lead to project failure. It’s important to include your developers as part of the migration project team early-on to ensure success.
Curious to learn more? Take a glace at our free AWS Performance Benchmark below.