A desktop release is thousands of installations you cannot take back, so it travels like a scheduled train. Move the release target from thousands of desktops to one centrally managed server-side deployment, and the gap between “done” and “delivered” collapses: users move to the new version at their next login, and rollback is controlled on the server side.
The feature was finished in March. A developer built it, tested it, demoed it, and moved on. Users first touched it in September. Nothing was wrong with the feature; it sat in a warehouse for six months waiting for the next release train, because that is how desktop software ships. The gap between March and September was not development. It was delivery, and it was the wrong problem being solved slowly.
“Premature optimisation is the root of all evil.” Donald Knuth wrote that about code, but it scales all the way up to companies. A rewrite undertaken “so that we can finally release faster” is the largest premature optimisation there is: years of cost committed against a bottleneck nobody measured. Most teams that measure it discover the bottleneck was never the code. It was the delivery.
If your team still packages installers, maintains a test matrix of operating systems times Java runtimes times client versions, and schedules releases like train departures, you already know the cost, because every desktop team pays the same tax and rarely says so out loud: finished features age in a warehouse waiting for the next train, while web-delivered competitors ship weekly. This article is about removing that tax without rewriting the application.
First, the three letters, because they are worth remembering. CI/CD stands for Continuous Integration and Continuous Delivery. In one sentence: it is the assembly line that takes a change a developer just made and gets it built, tested, and ready for users automatically, so that shipping software becomes a small routine event instead of a big scary one. Continuous Integration is the first half: every code change is automatically built and tested the moment it lands. Problems surface immediately instead of at a quarterly merge. Continuous Delivery is the second half: any change that passes those tests is ready to deploy. Releasing stops being rare and risky. It becomes routine: small changes, shipped often, each one easy to roll back. This is normal on the web. The obstacle for a Java Swing application was rarely the pipeline itself. It was the delivery target: thousands of desktops could not behave like one controlled server deployment.
The desktop release tax
Every desktop release pays it: packaging and installers, the compatibility matrix, a staged rollout, and then weeks of version skew, some users on the new build, some on the old, and support opening every ticket with “which version are you on?” Because the tax is paid per release, teams rationally release rarely, and the backlog of finished but unshipped work grows. The pain that starts most modernisation projects is exactly this delivery pain, not the user interface, a point worth separating carefully before anyone signs off on a rewrite.
The most unpopular change in software is an update
There is a second cost, quieter and larger. For users, an update is the textbook case of a necessary but unpopular change: an interruption, a download, a dialog, a small fear that something they rely on will move. The rule for such changes is simple: make them as painless as possible, ideally invisible. Browser delivery achieves exactly that. There is nothing to download and nothing to interrupt; users simply find the improvement there at their next login. They receive the benefits of change without ever experiencing a change event.
Centrally deployed, fully under your control
Webswing runs the existing Java Swing application centrally on the server, and users reach it through a URL in the browser, without turning the application into a new web application. Because the application runs centrally, a release is a server deployment: build the artefact, deploy it in one place, and users move to the new version at their next login. A critical bug fixed at lunch is fixed for everyone by the afternoon. Version skew does not disappear from the universe, but it stops being a client-side support problem: there are no longer four thousand desktops drifting out of sync, only a controlled deployment you operate.
A standard web pipeline, not a custom invention
This is the point to state plainly, because it is easy to over-claim: Webswing does not replace your CI/CD pipeline, and browser delivery is not CI/CD by itself. What it changes is the delivery target. In this model it changes the deployment topology of a Java Swing application: from many client installations to one centrally operated server-side runtime accessed through the browser. Once the target is a server-side artefact, the standard release practices used for web services can be applied to it.
From there, the release model starts to look familiar to any team already running web services, because the deployment target is now a server-side artefact. Webswing can be containerixed, orchestrated by Kubernetes, expose lifecycle and health endpoints, and reports through a REST metrics interface into Prometheus and Grafana. Pipelines build and test on every commit; session pools allow rolling deployments; rollback becomes a controlled server-side operation, usually redeploying the previous image rather than chasing client installations. Active sessions still need to be handled deliberately, but the rollback target is central and controlled. Small batches, every change releasable, rollback as a first-class citizen: none of it had to be invented for a Swing application.
This reversibility is the quiet core of the whole approach. Modernisation advances one small, releasable step at a time, and any step that misbehaves is rolled back without drama, the case for incremental modernisation over big-bang rewrites (a related earlier article is linked below): progress you can undo is progress you can afford to make.
The rewrite as premature optimisation
Return to Knuth. A rewrite justified by “we need to ship faster” optimises the whole company against an unmeasured bottleneck. Fix delivery first, which is days or weeks of work, then measure where time actually goes, and only then decide what else deserves rebuilding. Do it in the other order and you may spend three years rebuilding the application to gain a release cadence that changing the delivery target could have given you in a fortnight.
What the customer saw
The feature that once would have waited from March until September now landed within weeks of being finished. A reported bug was gone the same day, for every user, without anyone updating anything. What they did not see: an installer, a version number, or a “please upgrade” dialog, ever again. The transaction flow kept running through every single deployment. Continuity first, architecture in service of continuity.
What CI/CD does not fix
A pipeline does not write Swing code faster; it removes the release train from finished work. If development itself is slow, that is a different problem with different remedies. What the pipeline guarantees is narrower and still transformative: finished work reaches customers at the speed of the business, not the speed of the train schedule.
The customer saw a better product. The application never noticed.
Sources
• Martin Fowler, ContinuousDelivery (bliki: releasable software at any time via an automated pipeline)
• Martin Fowler, Strangler Fig Application (incremental modernization instead of big-bang rewrite)
• Related earlier article: Igor Gembula, Incremental Strategies for Modernizing Legacy
arrow_back_ios
