The Migration That Never Happened
The app reached the browser, the bridge worked, and nobody crossed it.
The migration project was announced with confidence. First, the old Swing application would be made available in the browser. Then the team would gradually rebuild its screens with modern web technology.
The first part happened quickly. People stopped installing local Java runtimes, deployment became central, remote users got a URL, and management celebrated the first visible result.
Then came the next release, the next budget cycle, and another urgent customer request. Three years later, the application still runs through the browser exactly as it did on day one. The bridge worked so well that nobody ever crossed it.
Browser delivery can remove the operational reasons that once justified a rewrite. The existing program runs in modern browsers without its source being converted, deployment is centralized, the runtime is controlled, and sign-on is handled. Browser delivery can also preserve enough desktop behaviour, from printing to local files, that the original operational pressure simply disappears. [1]
That is the paradox of a good transitional design: it can remove the very pain that made the transition feel urgent. Before, the problems were concrete and loud, awkward installation, incompatible Java versions, VPN access, slow rollout. Afterwards, the case for rebuilding is softer, better experience, accessibility, mobile use, lower cost, and none of it shouts as loudly as “the application no longer launches on customer laptops”. So an organization can settle onto the bridge and stay there, not by decision but by the absence of one.
Staying on the bridge is not automatically a failure. It becomes one only when nobody owns the next step.
Permanent browser delivery is a legitimate destination if it is named, funded, operated, maintained and staffed as the intended architecture. The failure is to keep calling it temporary while, year after year, nothing further is planned or paid for.
Ward Cunningham’s debt metaphor belongs here, used carefully. A shortcut is not a mistake; it can create immediate value. Debt appears when repayment is assumed but no owner, budget, schedule, migration units or retirement criteria are attached to it. [2] Reaching the browser is not itself a liability. It becomes strategic debt only when it is described as a stage while the cost of the next stage stays invisible.
The decision to stay is not free either. Meir Lehman’s work on software evolution is the counterweight: a system in active use keeps absorbing new requirements, and its complexity grows unless effort is spent holding it down. [3] Long-term delivery through the browser is a real choice, but not a finished or maintenance-free one.
Large rewrites assume that the destination will still make sense when the journey ends. That was easier to believe when platforms, deployment models and user habits changed more slowly. Today a rewrite may run for three or five years while the target moves underneath it. Frameworks change, security expectations rise, devices shift, workflows are redesigned, and users grow used to different interactions.
A replacement can therefore arrive already reflecting outdated assumptions. It may also bring a fresh set of defects, because a blank-page replacement does not begin with a blank business domain; it begins without many of the corrections the old system accumulated through years of real use. And even when the new system is technically sound, a replacement can fail socially if it changes expert workflows faster than users can absorb them.
Lehman’s point is not only that old systems keep changing. The environment around them changes too, and there is no final architecture after which an organization can stop adapting. The world is in permanent transition. Incremental replacement does not slow that down; it accepts it. Small production steps let an organization learn, adjust the target and absorb user reactions while the original system keeps carrying the business.
The hardest part of a long transition is usually not the technology. It is ownership.
Split by technology, a Swing team and a web team tend to produce handovers, duplicated rules, divergent priorities and gaps where nobody is responsible. Matthew Skelton and Manuel Pais argue that teams work best when aligned to a stream of customer value rather than a technical layer. [4] The binding constraint is cognitive load: whether one team can realistically hold the business domain, the desktop stack, the web stack and the transition machinery at once. The answer is rarely a single developer who knows everything, and more often a small cross-functional team that shares the load.
A migration organized around technology stalls. Organized around business capabilities, it can move.
The unit that matters is not “the Swing screens” but a capability: claims intake, reporting, approvals, customer onboarding, an underwriting workflow. Picture an application of a few hundred screens where most people spend most of the day in a couple of dozen of them. Delivered to the browser as it stands, it can then gain a web-based claims intake flow, then a document viewer, then a customer portal, while the dense underwriting screens used by trained assessors stay as they are. One cross-functional team owns both the old and the new version of a given capability, all the way through to retiring the old one.
A replacement that is not yet used, and an old path that is not yet retired, is not a migration.
Incremental renewal follows Martin Fowler’s strangler fig: new functions grow around the original until it can be removed. [5] Jez Humble and David Farley define continuous delivery as the ability to put changes into production safely and routinely, and the same discipline applies here. [6] The stages are recognizable. Delivery makes the application reachable in the browser and changes only distribution. Extension adds new browser-native capabilities around it. Selective replacement moves the highest-value workflows to web-native implementations. Retirement removes the previous version once the replacement proves sufficient in use. A stage is complete only when the new path runs in production and the old path can be switched off. Because each step reaches production, the next decision can respond to the world as it now is, not as it was when the programme began. Incremental delivery also shortens the distance between a design assumption and evidence from real users.
The most expensive stage has always been the actual rebuilding of screens. AI-assisted modernization tools, including Webswing’s current AI Modernisation work, are aimed at this expensive step: using AI to read existing screens and draft web-component versions of them, with a person steering the work and choosing the target technology. Such tools can lower the cost and uncertainty of selective replacement. They do not decide which capabilities are worth replacing, and they do not, on their own, retire the old path; the result still needs technical review, behavioural validation and product judgement. Lower implementation effort can make a strategy easier to execute. It does not substitute for having one.
A bridge becomes permanent when success is measured only as “available in the browser”. Staying deliberate takes a few habits.
Name the destination. Choose permanent delivery, a lasting mix, selective replacement or full retirement, provisionally if necessary.
Define units that can disappear. Use workflows or business capabilities, each with an owner, an intended outcome, an adoption threshold and a retirement decision. The retirement test is business sufficiency, not feature-for-feature parity.
Separate maintenance from renewal. Transition work rarely survives in the same backlog as production incidents, where the emergency always wins.
Measure retirement. Track activity moved, workflows stood down, duplicated rules removed and support load reduced, not just screens added.
Schedule decision points. Every six or twelve months, decide to continue, stop or change direction. A choice to stop can be valid; a migration that stops because nobody was watching is not.
Revisit the target. A plan can stay on schedule while its assumptions go out of date. At each decision point, ask not only whether the programme is progressing, but whether the destination chosen earlier still fits current users, technology and economics.
Browser delivery solves distribution at once. Renewal still depends on ownership, budget and explicit retirement decisions. Permanent delivery can be the intended architecture, or it can support gradual replacement, and both are real decisions. What is not a decision is continuing to call the bridge temporary while funding only its upkeep.
The world will not pause while the migration finishes. User expectations, technology and the business itself will keep moving. The practical answer is not a final transformation after which change stops, but an architecture and an organization able to change in small, deliberate steps.
A bridge is not a plan. Decide whether to cross it, live on it, or keep it on purpose, and do not wake up three years later to find that the migration never happened.
1. Webswing. “Overview.” Webswing Documentation, version 26.1. https://www.webswing.org/docs/26.1/overview
2. Ward Cunningham. “Ward Explains Debt Metaphor.” c2.com. https://c2.com/cgi/wiki?WardExplainsDebtMetaphor
3. Meir M. Lehman. “Programs, Life Cycles, and Laws of Software Evolution.” Proceedings of the IEEE, 68(9), 1980. https://ieeexplore.ieee.org/document/1456074/
4. Matthew Skelton and Manuel Pais. “Team Topologies: Organizing Business and Technology Teams for Fast Flow.” IT Revolution Press, 2019. https://teamtopologies.com/key-concepts
5. Martin Fowler. “Strangler Fig Application.” https://martinfowler.com/bliki/StranglerFigApplication.html
6. Jez Humble and David Farley. “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.” Addison-Wesley, 2010. https://continuousdelivery.com/
