Palisis Frontend Modernization: From GWT to Angular Without a Forcing Function

The Context

The Palisis Backoffice is the operational core for travel and tour operators — booking, ticketing, resource planning, and reporting all run through it. It was built on Google Web Toolkit (GWT), a framework that compiled Java into JavaScript and served the product well for years.

Over time, GWT’s structural limits began to constrain the product: monolithic bundles, DOM slowness, framework obsolescence, and a steadily narrowing developer hiring pool. None of this had broken anything yet — which is precisely why acting early mattered.

Three Compounding Constraints

• GWT development had effectively ceased. Active development stopped and the community thinned, leaving the framework on a slow path to obsolescence.
• Modern UX requirements were blocked. Responsive layouts, dynamic composition, and interactive overlays meant working against the framework rather than with it.
• The developer pipeline was narrowing. The skill set was niche, and the hiring pool kept shrinking.

Our Approach

Kansoft chose the harder, lower-risk path: a parallel-running, module-by-module migration executed before technical debt forced a rushed rewrite.

1. Framework decision. Angular was selected for its component-based architecture and active LTS roadmap. The frontend was decoupled from the Spring backend through explicit API contracts.

2. Parallel-running model. Both the GWT and Angular systems run live in production at the same time. Users are never pushed onto incomplete surfaces.

3. Module-by-module migration. Each module is fully understood before it is rebuilt, and every GWT assumption is interrogated rather than copied forward.

4. Quarterly version cadence. The team moved v14 → v15 → v16 → v17 → v18 with no versions skipped, deliberately absorbing each release’s capabilities as it landed.

5. Clean cutover. Every GWT module is rebuilt and validated before decommission, with the full cutover targeted for the close of 2025.

Before and After

Aspect	Before (GWT)	After (Angular)
Frontend framework	Google Web Toolkit (dev ceased)	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
UX ceiling	Fight the framework	Composition by default

What the Migration Unlocks

• Composition-heavy product surfaces — complex nested UIs and dynamic state
• Direct-DOM interactive surfaces — real-time rendering and spatial visualization
• User-configurable screen layouts — per-user preferences
• Customizable reporting dashboards — composed from a shared component library
• Modular feature rollouts — discrete features shipped independently
• Frontend ↔ backend decoupling — teams maintain and release on independent cadences

Why This Engagement Stands Out

• Migration without a forcing function — proactive, strategic execution before technical debt compelled action.
• Parallel-running discipline, not rewrite shortcuts — the harder approach, and the one that protects the business.
• Framework investment, not framework adoption — v14 through v18, with each release’s capabilities deliberately absorbed.
• Decoupling as an outcome, not a side effect — Angular and Spring now evolve on independent cadences.