Why a from-scratch rewrite of a twenty-year-old Java Swing application solves the wrong problem, and how Webswing modernises the user experience without re-authoring the business underneath.
Somewhere in the code of a twenty-year-old application is a comment that reads only “do not touch this, ask Pavel.” Pavel retired in 2019. Since then nobody has touched it, and nobody has dared propose rewriting it. The code simply runs the business, day after day, not only this company’s but its customers’ too.
For two decades those customers have built their working day around that application: the habits, the routines, even the offline rituals, the way a clerk names a folder or stacks documents on a desk, all shaped around how it happens to work. Nobody loves it. It is load-bearing. Melvin Conway named the mechanism in 1968: a system comes out shaped like the organisation that built it. The corollary nobody mentions is what happens when that organisation retires and a new team is hired to build it again.
Then a request arrives. The world has moved on, management says; the interface looks dated and the users deserve better, so the application needs modernising. Pavel’s comment, meanwhile, is still sitting in the code: do not touch this.

The rewrite that hires a new company
And the modern-sounding way to deliver that, everyone agrees, is to rewrite it from scratch, on a clean web stack, with a fresh team. But a clean web stack is not automatically a clean migration; it is often a new product pretending to be the old one. By the same law that shaped the original, a new team produces a different application, shaped like different people. The risk was never that the new interface looks different. The risk is that it behaves as if twenty years of operational knowledge never happened.
Much of that knowledge is written down nowhere. Over twenty years, a handful of bugs quietly became features, behaviours people now depend on precisely because they were never fixed, and nobody will program them back on purpose, because nobody remembers they are load-bearing until they are gone. Users feel it the first time a sequence their hands have known for fifteen years does not answer the way it always has. You do not quietly pull out a load-bearing wall while everyone is still living in the house.
And the whole time, the clock runs. A from-scratch rewrite freezes the product for two or three years while every hand rebuilds what already worked and competitors keep shipping. The cruelest detail is the original brief: nobody set out to re-author a decade of business logic. The goal was to modernise the user experience. That was it.
The UX was the problem. The rewrite was the overreaction.
Step back to what anyone actually asked for. Users were not requesting a new architecture; they wanted easier access, a screen they could open from a browser instead of only from their one office desktop, so the same tool would be there from a home office or anywhere else, less friction, a cleaner surface. IT wanted security, single sign-on, and a rollout that did not involve touching four thousand machines. Management wanted continuity and lower risk. Not one of those needs requires rewriting the business logic. A rewrite answers a question nobody asked. The useful question is narrower and far less dangerous: not “how do we rebuild this application,” but “what actually needs to change for the people who use it?”
Modernize the experience, not the system
That is the modernisation most long-lived Swing applications, and other legacy desktop applications, actually need: change what users touch, not what the business depends on. Webswing enables exactly that, UX modernisation for a Java desktop application without rewriting the business logic underneath. Its documentation describes it as a specialised web server that runs Java desktop applications directly in the browser with no code changes, built for organisations that want to modernise existing Java desktop applications without rewriting them from scratch. The application keeps running as it is, and the experience around it moves forward: it opens in any browser behind single sign-on, with nothing to install, the same trusted workflow now easier to reach, faster to onboard, and consistent across every environment. Modern UX, here, does not mean new behaviour. It means better access and a cleaner surface over a workflow people already trust.
And when you want to refresh the interface itself, there is Webswing’s Facelift (the name undersells it; the page and the documentation are linked in Sources below). It is not a cosmetic skin. It works as a layer between the browser and the running Swing application, where modern styling and native web components are mapped onto the existing Swing components, so the very controls your users already know are re-skinned to look genuinely new, without the application itself being touched. The business logic and the underlying component tree stay anchored, and the change is reversible. The look moves forward; the twenty years beneath it do not move at all. That is also the quiet answer to adoption: refresh the surface and keep the muscle memory, and adoption rises, because nothing was taken away. For a long-lived Swing application, the safest modernisation path is to preserve the application model and modernise the delivery and experience around it.
Ask Pavel
Pavel is not coming back; he has a garden now, a happy crop of zucchini, and no intention of returning. His comment is still in the code, and it is still correct: do not touch this. The good news is that you no longer have to. Modernisation does not have to mean replacing the thing your business depends on. Sometimes the most modern decision is to keep the system that works, move it to the browser, and modernise the way people experience it, leaving Pavel’s twenty years exactly where they are, quietly bearing the weight, shaped like the company that, after all this time, is still you.
Sources
• Webswing, Live Migration Demo
• Melvin Conway, How Do Committees Invent? (Datamation, 1968); Conway’s Law
• Herb Caudill, Lessons from 6 software rewrite stories (you cannot ship while you rewrite)
