When a Swing application runs the business, modernisation is not just a technology choice. It is a continuity problem: keep the product earning, keep customers served, and move toward the web without forcing an irreversible rewrite on day one.
A company came to us with a familiar problem. Their core product was a large Java Swing application, built over many years, used every day by customers, and responsible for a meaningful part of the company’s revenue. Everyone agreed on the direction: the application had to move toward the web. The dangerous question was how.
Because when a Java desktop application runs the business, modernisation is not just a technology project. It is a continuity problem. Customers still need improvements. Support still has to work. Licences still have to renew. The company cannot put the product on pause for several years while a new web version is built somewhere else.
That is where many modernisation projects make their first irreversible mistake. They turn “we need to move from Java desktop to web” into “we must choose the final web stack today and rewrite everything into it.”
When the application is the business
The business requirements are not abstract. The application has to keep evolving. Customers have to keep receiving the improvements and new features they ask for. Support has to keep answering real production issues. Licence renewals have to stay justified. Sales cannot explain a three-year feature freeze by promising that the future version will be beautiful when it finally arrives.
When the application is the business, modernisation cannot be allowed to stop the business. For a company whose Swing application is also its product, modernisation has to protect revenue first and architecture second.
The target is web. The name and the date are not.
Be honest about the target: the long-term direction may well be a web-native application, and that is a fair ambition. The uncomfortable part is the timeline. Today the candidates are easy to name. React, Angular and Vue lead the fashion, Vaadin and webforJ court the Java crowd directly, and each camp is quietly certain that its framework is the obvious destination. Step back a little and the certainty looks thinner. Front-end fashion turns over every few years, and whichever name looks dominant now has no guarantee of still being the sensible target in five or ten, by which time the winner might be something not yet born. Pretending you can crown it today is how decade-long bets go wrong. Name the destination too precisely, too early, and you can arrive on schedule at a place that no longer exists. Good engineering already knows this: you make the irreversible decisions at the last responsible moment, not the first exciting one.
The rewrite is a one-way door
Jeff Bezos sorts decisions into two kinds. Some are two-way doors: you walk through, and if you do not like what you find, you walk back. Others are one-way doors, consequential and hard to reverse, and they deserve to be made slowly.
A full rewrite of a business-critical Swing application is a one-way door. You choose the target stack before you really know whether it will fit. You freeze years of accumulated behaviour into specifications. You ask customers to wait while the old product ages and the new one is not ready yet. And if the bet turns out to be wrong, walking back is painfully expensive. A rewrite may be an architecture plan, but for a company whose Swing application pays the bills, it is also a revenue-risk event.
Webswing is the two-way door
Browser-first modernisation is the other kind of door. It lets the existing application keep running, keep earning, and keep evolving while the target state becomes clearer. Webswing runs the existing Swing application in the browser with no source-code changes, so delivery is solved now and the product keeps shipping features the whole time. From there you modernise incrementally, refacing or rebuilding screens when they earn it, in whatever web technology is right when you reach them, while the rest keeps running and keeps earning. Every step is reversible. The target state is not abandoned but approached one step at a time, allowed to sharpen as the landscape does. The rewrite is the one-way door. Webswing keeps the door swinging both ways.
The best target is one you can still change
The long-term direction may well be web-native. But the business does not have to freeze while that target becomes clear. You do not have to name the destination, in full, on day one to start getting there, and you certainly should not turn a ten-year guess into a one-way door. Keep the application evolving, keep customers renewing and satisfied, keep the business growing, and let the final shape of “web” reveal itself while you are already in motion. The best target state is the one you can still change your mind about.
Sources
• Jeff Bezos, 2015 Letter to Amazon Shareholders (one-way vs two-way door decisions)
arrow_back_ios
