How to move a Java Swing application to the web when nobody left actually knows Swing, why Webswing is the right solution, and how you migrate step by step to any web technology you choose.
A company we now count among our good friends came to us a while ago in a panic we know very well. Their core application, the one the whole business stood on, was a large Java Swing system built over many years by a small, brilliant, and by now almost entirely retired team. The application still ran beautifully every single day. Its authors did not. They were scattered across various beaches, comparing pensions, relitigating the architecture decisions of 2009, settling once and for all who had been right back then and who had been wrong, reminiscing about the cars they used to drive, debating who had claimed the best per-diems on which business trip and why expense policies simply aren’t what they used to be, and remembering which Java conference had been the most thrilled to have them in the room.
What none of them were on hand to answer, of course, were the only questions that now mattered: how do you get a business-critical Java Swing application into the browser quickly, how do you keep modernising it while it has to stay in production around the clock, and do you rewrite the whole thing or move one step at a time?
Their job posting told the whole story: “Senior Java Swing Developer, 10+ years’ experience, immediate start.” Open for months, zero suitable applicants, because the suitable applicants were the very people who had just left. Leadership had landed on the obvious fix, move it to the web, which everyone in the room translated into a single word: rewrite.
Here is the part we had to say out loud, gently. A rewrite, by hand or with an AI tool, begins by having someone read every old screen and work out exactly what it does, so it can be faithfully rebuilt. That someone has to be fluent in Swing. They had just spent months proving they could not hire anyone fluent in Swing. The plan to escape a dying skill depended, entirely, on the dying skill. It was, with affection, the corporate version of “I’ve lost my glasses, everybody help me look for my glasses.”
So we suggested the opposite of a rewrite
Keep the application exactly as it is, and change only how it reaches people. Webswing runs an existing Swing application in the browser with no source-code changes: the real application, unchanged, reached through a URL. We have done this in production since 2012, which is precisely why it fit them so well. The one thing they were short on was Swing expertise, and Webswing asked for none of it.
Within days, not quarters, the application was in the browser. The delivery pain that had started the whole conversation was simply gone: no more desktop installs, no client-side Java runtime to manage, no dependence on dead channels like Java Web Start (removed in JDK 11) or applets (removed in JDK 26), no VPN and Citrix tax. Nobody had touched a line of Swing, because nothing in the application had changed. The app kept running. Nobody had to read it, understand it, or be hired to maintain a skill the market no longer sells.
Then they moved off Swing, at their pace, into any technology
That could have been the end of the story, and for some applications it should be. But they wanted to keep going, on their own schedule, and this was the part they liked most. With the application live and stable in the browser, you can modernise one screen at a time and choose the destination yourself: React, Angular, Vue, plain web components, whatever your team can actually hire for today. Webswing let them rebuild screens in the technology of their choice and run those screens alongside the original, so new web UI and untouched Swing lived inside one application while the migration went on around it.
The new screens were built by web developers, not Swing developers. The Swing underneath simply ran until its turn came, and when one experiment did not work out, they stepped back, because the original was never touched. That is the move a rewrite cannot make. A half-modernised application runs in production perfectly well: some screens new, most original, all working. A half-rewritten one is a construction site with the power off, staffed, naturally, by the exact people you could not find.
They are still modernising today, years later, at exactly the pace that suits them: no rewrite, no big bang, no frantic hunt for retired Swing experts. Somewhere along the way they stopped being a customer with a problem and became good friends of Webswing. The retired developers, as far as we know, are still on the beach. These days, nobody needs to call them.
Sources
• Webswing, Modernisation Framework (Rebuild in the technology of your choice, step by step)
