Mixed In

A lead engineer was making his case to a VP about Node.js end-of-life migration.

Support expires. Security patches stop. Vulnerabilities pile up. Technically, he was right. The VP's response was flat. "And what does the user get out of it?" The engineer had no answer.

I was sitting nearby, thinking: that's not how you sell it.

Back when I worked at a contract development shop, Rails version upgrades burned us over and over. Every major version broke compatibility, and we scrambled to fix things under the pressure of EOL deadlines. For the client, this kind of migration produced no business value. The screens looked the same. No new features. No faster response times. Just billable hours. Every time we submitted an estimate, we got the same grimace.

At the same company, there was a system written in Perl. Almost no changes ever went in. Aging code, running quietly. To the stakeholders, that looked normal. Don't touch it, it won't break. Why does Rails cost money when Perl doesn't? Answering that question is harder than engineers think.

Kubernetes is the same story. I've watched plenty of teams running just to keep up with support windows.

One thing stays constant across every project. Stakeholders don't want to pay for fixes that produce no business value.

I don't know the right answer. But I wouldn't propose EOL migration on its own. Be upfront about the risk. Then bring a proposal that also adds new features or solves existing pain points. We're updating the foundation, and here's the value we can deliver along the way.

Technical correctness alone doesn't move an organization. You need to attach something the other side actually wants.

I wanted to tell that lead engineer. I kept quiet. Don't fight battles you can't win. Once someone decides "no value here," everything you say gets painted the same color. You have to reset the conversation.