When 'It Works' Becomes the Problem

Not long ago I worked on a system stuck in the Microsoft world .NET 4.8, MSSQL, SSIS, Windows Server 2019 etc. Everything tied to Visual Studio, AD and tools that only ran on Windows.

No documentation. Logic hardcoded everywhere. The team knew the system well, but they had been inside it so long that questioning choices felt pointless. “It works” was enough.

I saw problems like onboarding would be painful. The code was fragile. Vendor lock-in was risky. Nobody wanted to improve things. No sense of ownership, just keep it running.

Then came the push to move to .NET Core. That’s when it all hit. Libraries missing. Windows specific code everywhere. Authentication, services, deployment all locked to Windows. The transition was a nightmare.

That’s the thing about vendor lock-in. It feels easy short term. But long term it kills flexibility. Change gets harder. Hiring gets harder. Your stack ages faster than you think.

From the inside everything seemed fine. The client didn’t know tech, the system ran and the team was comfortable.

From the outside it looked like rot. Not broken yet, but slowly decaying. Debt piling up year after year.

I like working on legacy code. But this one was different. It wasn’t just old code—it was a culture. Afraid of change. No motivation to improve. Suspicious of improvement.

“It works” is not the same as “it works well.” The longer you wait to fix it, the harder it gets.