Practice
Frontend Modernization · Custom Software Engineering
Frontend Modernization · GWT → Angular
Palisis Backoffice rebuilt on Angular.
No forcing function. No business disruption.
GWT's structural ceiling — monolithic bundles, DOM slowness, framework obsolescence, a hiring pool narrowing year over year — would have eventually become a forcing function. Palisis decided not to wait. Kansoft re-architected the Backoffice frontend on Angular through a parallel-running, module-by-module migration starting September 2022. Both systems live in production. Cutover targeted for the close of 2025.
v14 → v18 Angular cadence Module-by-module migration Cutover close of 2025
Context
A framework that had stopped keeping up with the product it was meant to deliver.
Palisis Backoffice is the operational core platform for travel and tour operators — booking, ticketing, resource planning, reporting. For years it ran on Google Web Toolkit: Java compiled to JavaScript, DOM addressed through an opaque widget tree. It was a defensible choice at the time. Backend-oriented teams could ship web UIs without becoming frontend specialists.
Then the framework's ceiling started showing. Bundles were monolithic by design. Rendering grew progressively slower. Fine-grained UI composition wasn't structurally possible inside the widget tree. Modern product features — responsive layouts, dynamic composition, interactive overlays — required working against the framework rather than with it.
GWT itself effectively ceased active development. The community thinned. The hiring pool narrowed. The gap between what product wanted to build and what the stack could deliver kept widening. There was no single incident, no crisis. The migration trigger was a proactive strategic decision — exactly the kind of decision most organisations defer until tech debt becomes a forcing function.
The Constraint
The forcing function had not arrived. But the trajectory had already decided.
Three constraints were compounding quietly. None alone justified a migration. Together they were going to cost more every year than they cost the last.
01
GWT had quietly stopped moving
Active development effectively ceased. The community thinned. There was no security or browser-update safety net being maintained by anyone except, eventually, Palisis itself. Obsolescence wasn't theoretical — it was compounding.
02
Modern UX required fighting the framework
Responsive layouts, dynamic composition, interactive overlays — every product direction the business wanted to go required working against GWT's widget tree, not with it. The framework had become the constraint, not the enabler.
03
The developer pipeline was narrowing
Build cycles were slow. The skill set was niche. The hiring pool kept shrinking. The gap between what the product roadmap wanted and what the delivery capacity could ship was widening — and only one of those two was going to bend.
Approach
A frontend migration is a discipline problem, not a framework problem.
We structured the engagement in five phases — each gated, each deliberate, each designed to make the next one safer rather than larger. Framework choice came first. Parallel running came before module migration. Version cadence was committed to up front. The cutover was named at the start, not at the end.
PHASE 01
Framework Decision
Angular chosen for component-based architecture, opinionated conventions that resist drift, and an active LTS roadmap that directly addressed GWT's obsolescence risk. Backend decoupled via API contracts — not a popularity decision, a structural one.
PHASE 02
Parallel-Running Model
Both systems live in production simultaneously. GWT Backoffice never went offline. Users were never forced onto an incomplete Angular surface. The parallel model imposed the discipline that a rewrite would have skipped.
PHASE 03
Module-by-Module Migration
Each module deeply understood before rebuild. Every GWT assumption interrogated: intentional behaviour or framework artefact? Interdependent modules, complex state, multi-domain workflows — re-decomposed instead of carried forward.
PHASE 04
Quarterly Version Cadence
v14 → v15 → v16 → v17 → v18. No versions skipped. Every release absorbed its key capabilities — typed forms, standalone components, required inputs, new control-flow syntax, Signals API. Framework investment, not framework adoption.
PHASE 05
Clean Cutover
Targeted for the close of 2025. Every GWT module successfully rebuilt and validated in Angular before decommission. Not a gradual fade — a deliberate exit. No legacy modules remaining live.
What We Built
An Angular Backoffice. A Spring backend decoupled at the API contract. A migration model the team can run again.
The deliverable was not the new Angular UI. The deliverable was a frontend organisation that ships modularly, stays current with its framework, and is no longer compiled together with its backend. The Angular code is the artefact. The way it gets shipped — and kept current — is the outcome.
01 · Angular component tree
GWT's opaque widget tree replaced by an Angular component architecture — separation of concerns at module level, independent testability, dependency-injected services. Fine-grained UI composition that was architecturally impossible on GWT is now the default.
02 · Frontend ↔ backend decoupling via API contracts
Angular and the Spring backend are no longer compiled together. They communicate through API contracts, evolve on independent release cadences, and can be maintained by specialised teams without cross-stack cascades.
03 · Module-by-module replacement under parallel running
Every GWT module rebuilt in Angular and validated against production before the legacy version was decommissioned. Users stayed on a working system throughout. Stakeholder confidence held because no one had to bet on an incomplete UI.
04 · Version stewardship as architectural investment
Quarterly upgrades through v14 → v15 → v16 → v17 → v18, no versions skipped. Each release's capabilities (typed forms, standalone components, required inputs, new control-flow, Signals) absorbed deliberately — version currency treated as active stewardship, not optional maintenance.
Migration Architecture
Angular Version Cadence
Five releases. None skipped. Each absorbed deliberately.
Version currency was a commitment, not an afterthought. Every Angular release between v14 and v18 was adopted on a planned quarterly cadence, and the capabilities each version introduced were folded into the architecture rather than parked for later.
Angular v14
Typed forms · functional guards
Angular v15
Standalone components · functional interceptors · image directive
Angular v16
Required inputs · router input binding
Angular v17
New @if / @for / @switch control flow
Angular v18
Signals API stabilisation (current)
What Changed
The framework stopped being the ceiling. The product roadmap stopped negotiating with the stack.
These are the outcomes the Palisis team plans against now. None of them are reversible — and none of them required a forcing function to start.
Five major Angular versions absorbed — none skipped
Quarterly cadence maintained from v14 through v18, with each release's capabilities folded into the architecture
Frontend and backend decoupled via API contracts
Angular ↔ Spring evolve on independent release cadences; no cross-stack cascade on changes
Zero forced cutovers onto an incomplete system
GWT Backoffice fully operational throughout; users never moved before a module was validated
Clean cutover targeted for close of 2025
Every GWT module rebuilt and validated in Angular before decommission — no legacy left live
| Measure | Before · GWT | After · Angular |
|---|---|---|
| Frontend framework | Google Web Toolkit (ceased active dev) | Angular v18 (active LTS) |
| Bundle model | Monolithic compiled output | Modular, lazy-loaded |
| Release cadence | Full system rebuilds | Discrete feature rollouts |
| Backend coupling | Compiled together (Java → JS) | Decoupled via API contracts |
| Module composition | Opaque widget tree | Component-based, independently testable |
| Hiring pool | Narrowing, niche skill set | Mainstream Angular / TypeScript talent |
| UX ceiling | Fight the framework | Composition is the default |
| Tech-debt trajectory | Compounding | Actively stewarded |
What the Migration Unlocked
Features the product team had wanted to build for years. Now possible by default.
The strongest evidence that a frontend migration was the right call is the work it made possible. None of the items below existed in the GWT Backoffice. All of them were either built post-migration or are now structurally available where they previously weren't.
Composition-heavy product surfaces
Complex nested UIs, heterogeneous data shapes, dynamic state — surfaces that were structurally blocked on GWT's widget model. Built post-migration on Angular's component architecture, where composition is the default rather than the workaround.
Direct-DOM interactive surfaces
Real-time interactive rendering, spatial data visualisation, contextual overlays. The GWT DOM abstraction was incompatible with the interaction model the product wanted; Angular's direct DOM control made it tractable.
User-configurable screen configuration
Each operator now sets their own interface layout preferences — a capability that did not exist on GWT at all. Per-user composition is now a baseline, not a feature request.
Customisable reporting dashboard
Operators compose their own dashboards from a library of charts and data-table types. Dynamic component composition like this was architecturally impossible inside GWT's widget tree.
Modular feature rollouts
Discrete features now ship independently, without full system rebuilds. The delivery cadence and risk profile across every business domain changed in the same step — and they are not going back.
Frontend ↔ backend decoupling
Angular and Spring connect through API contracts. Independent release cadences, specialised team maintenance, no cross-stack cascade on changes. Decoupling is a modernisation outcome in its own right — not a side effect.
Engagement
How the work was shaped.
Tech Stack
Angular v18 · TypeScript · Spring (backend) via API contracts
Timeline
Started September 2022 · Cutover close of 2025
Delivery Model
Parallel-running migration · module-by-module · quarterly version upgrades
Why Kansoft
Frontend migrations fail in predictable ways. This one didn't.
Crisis-driven rewrites that ship late. Big-bang cutovers that strand users on broken UI. Framework adoption that quietly stops at v14 and never moves again. The engagement was structured specifically to prevent each of those failure modes — not to recover from them.
Migration without a forcing function Proactive, strategic, executed before tech debt forced the decision. Compounding obsolescence, UX limits, and developer-experience decay reinforce each other; we treat them as a business risk, not a future problem.
Parallel-running discipline, not rewrite shortcuts Harder than a rewrite — and precisely why it produces a better outcome. The constraint forces every GWT assumption to be interrogated rather than copied, and users stay on a working system throughout.
Framework investment, not framework adoption Version currency is active architectural stewardship. v14 → v18 with no versions skipped, each release's capabilities absorbed deliberately. The migration ends; the stewardship doesn't.
Decoupling as an outcome, not a side effect Angular ↔ Spring via API contracts. Frontend and backend on independent release cadences. The decoupling is what makes the next decade of delivery cadence look fundamentally different from the last one.
Carrying a legacy frontend?
Compounding tech debt is a business risk. Don't wait for the forcing function.
If your product team is negotiating with the framework, your hiring pool is narrowing, and your roadmap keeps bending around what the stack will allow — the calculus has already shifted. We've done this migration before, parallel-running and without disrupting the business that depends on it. We can do it for yours.
Speak with our Frontend Modernization teamConfidential · No procurement obligation · Response within one business day