Web System Migration Isn't Always the Right Call

If you’ve been in this work long enough, this proposal keeps coming back:

“Let’s migrate the old system to the web.”

Local app → web system. A familiar story.

But every time, I find myself asking,

Do you actually need this?

”Old” doesn’t mean “broken”

When you take work as a developer, you usually don’t think too hard about whether it’s necessary. A request comes in, you build.

But out in the field, you regularly run into systems where the honest answer is:

“This is fine. It still works.”

Of course, there are real reasons to consider a replacement.

These are legitimate. But “legitimate reason” doesn’t automatically mean “rewrite the whole thing.”

For example, EOL.

👉 Wrap the middleware in Docker on AWS to extend its life.

I’ve done this multiple times. Even after OS or middleware support ends, containerizing and isolating it can buy years of additional runway.

“We have to replace it or it won’t run” is often a story people have been told — not a fact about the system.

”While we’re at it, let’s redo everything” is the real trap

This is where things go wrong.

The pattern that almost always blows up:

“Since we’re doing it anyway, let’s overhaul the business processes too.”

This will, with very high probability, become a fire.

The reason is simple:

That’s the same thing as building a brand-new system.

And the client almost always says:

“It’s a refresh of an existing system, so it should be cheap, right?”

No. It’s actually more expensive.

In other words,

👉 You’re doing greenfield development with extra constraints.

Sometimes harder than starting from scratch.

Web is a tradeoff, not a victory

Web has upsides:

But on the other side:

For business systems especially, it’s not unusual to hear users say “the old desktop version was faster” after a web migration.

Sometimes paying the license, or covering it through operations, is the more rational call.

👉 A technically correct decision is not always a business-correct decision.

When you’re being sold something you don’t need

This is one I’d rather not say out loud, but it’s real.

Over a decade ago, I saw a consultant’s proposal stuffed with features that obviously weren’t needed. Looking from the technical side, you could tell it was “padded” — written for a buyer who couldn’t easily push back on the technical content.

“DX.” “Modernization.” “Cloud migration.”

These words sound right, and they aren’t wrong on their own.

But pulled along by them,

👉 the project ends up far larger than what was actually needed.

In the worst version of this:

“What didn’t need to be done is dressed up as something that has to be done.”

Not all of it is like this. There are plenty of valuable proposals out there. But:

“Does it actually make sense to do this now?”

If the buying side doesn’t ask this themselves, they end up carried by someone else’s logic.

Conclusion

Web migration is a means, not an end.

Without thinking through these,

👉 you end up with an expensive replacement of software that was already working.

As a developer, getting the work is fine. But honestly, I keep thinking:

“Does this really need to happen?”

I wish more people on the buying side carried this question, too.