Some tips for technology/stack migration from a management point of view

 I uploaded this meme to Reddit recently 

We all have this guy...

( https://www.reddit.com/r/ProgrammerHumor/comments/wjwd9k/i_am_that_guy/?utm_source=share&utm_medium=web2x&context=3 )

Sometimes this guy will make more harm than good, and sometimes he saves the company. 

The technology is very important to the development lifecycle - a wrong stack could make the development team chase themself fixing things, chasing errors and system crashes, and needing to overdesign features. Sometimes it's so severe that the development teams cannot develop anything new - at this point probably the company will die. This might also cause a hiring spree (that most likely won't solve the issue) as I explained before.

Yet so many fail that, including me, and here is just one example.

Let's see some famous myths:

• "Everyone uses this technology so it must be good for us as well" - wrong. The Helm example above is just one example. Different companies have vastly different use cases and constraints, a stack that fits one company could cripple another. 
• "X technology is so new and trendy so we must use it" - well.. no. New technology is usually not mature and many times can change its interface during its usage of it, which many times cause huge pain for developers. Its important to also understand why its trendy and for what use cases. The general rule that if you stack is maintained and actively developed, you probably should not move unless for other reasons. 
• "X technology is so much faster than ours" - Well, C programming language is much faster than many of the currently used programming languages, yet it's barely used. Writing in Python/NodeJS/Java and so on is so much simpler, and the cost difference at the bottom line is not that bad for most companies. This constraint rarely is an excuse for such a big move.
  
• "X technology has so many libraries we can use" - But what state of those libraries? how mature are they? What libraries it does not have? NodeJS vs PHP is a good example, where PHP has less libraries, yet the feel for me that PHP libraries like ORM are much more mature and maintained by proper professionals while >95% of NodeJS libraries are a bunch of kids having a side project with very basic knowledge of how to create proper code or anything functional. 

How can we avoid those myths' pitfalls?

Put non-technology constraints on the migration process. 

• How much money are we going to reduce in our hosting bill?
• By how much time it will reduce the development of let's say Y feature from the current X days?
• How the current maintenance time will be reduced? and by how much?
• What do other companies/communities similar to ours think about the specific X technology?
• Including risk (that things would not go as planned) + migration costs (manpower and other) - what is the ROI of the migration?

It's important to be open to migrations to other technologies and stacks, otherwise, there is a good chance the company will hit a wall and get stuck completely. It's also important to anyone suggesting a migration should have a good plan answering all the above and explaining that any myths entering the plan will be ignored.