India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Legacy UI Modernization: Replacing Forms, VB6 and WebForms Screens
Legacy UI modernization replaces ageing front ends, such as Oracle Forms, VB6, PowerBuilder, Java Swing, WebForms or JSP screens, with modern web or mobile interfaces backed by APIs, while keeping business workflows intact. NTSPL maps real user journeys, builds a design system and backend-for-frontend APIs, and migrates screens incrementally for operations-heavy businesses whose staff, partners or customers still work in decade-old screens.
Delivered on
In scope
Why old screens cost more than their hosting
Front ends age differently from back ends. A VB6 dispatch console or an Oracle Forms order screen may sit on a perfectly serviceable database, yet it needs a thick-client install, Citrix or IE mode, runs only on Windows desktops, cannot be used on a tablet at the ramp or in the warehouse, and takes new staff three weeks to learn because 40 function keys do the work. Business rules often hide in the interface, in form triggers and button handlers, so a straight re-skin breaks logic nobody documented.
NTSPL starts with observation, not screenshots: we shadow users, time tasks and count keystrokes on the 20 most-used screens. Rules buried in the UI are extracted into backend-for-frontend APIs, tested once and shared by web and mobile. New screens are built in React or Angular on a design system meeting WCAG 2.2 AA, and released journey by journey inside a shell that links old and new screens under single sign-on. Power users keep their keyboard shortcuts, because losing them is the commonest reason replacement UIs get rejected.
When front-end replacement is worth funding
Signals you need Legacy UI Modernization
- Applications need Citrix, IE mode or specific Windows builds only because the client is VB6, PowerBuilder, Forms or ActiveX.
- New staff take more than two to three weeks to become productive on core screens.
- Field, warehouse or ramp staff need the application on tablets or phones, but only desktop clients exist.
- Partners or customers get information by phone or email because the UI cannot be exposed beyond the LAN.
- Accessibility, browser-support or security reviews fail on the current front-end technology.
When to choose something else
- If the back end itself is slow or unmaintainable, modernize services or data first (Microservices or Managed Database Modernization) and build the new UI on top.
- If a packaged product's next version already ships a web UI, upgrade rather than rebuild.
- If only a visual refresh is wanted with no workflow or API change, a theme update inside the current framework is cheaper.
UI modernization work packages
Journey discovery
Task timing, keystroke logs and shadowing on the busiest screens, producing journey maps of steps to keep, merge or remove.
UI logic extraction
Validations, calculations and workflow rules pulled out of form triggers and event handlers into tested APIs.
Design system
Component library with tokens, data-dense tables, full keyboard navigation and WCAG 2.2 AA conformance.
Backend-for-frontend APIs
Screen-oriented APIs that aggregate legacy services, with caching and enterprise SSO.
Coexistence shell
Navigation shell or micro-frontend host linking new and legacy screens during transition.
Offline and mobile
Progressive web app with offline queueing for field users where journeys need it.
How Legacy UI Modernization Works, Step by Step
Shell-and-BFF Pattern for Screen-by-Screen Replacement
A web shell hosts the new screens and links to remaining legacy screens under single sign-on. Each new screen calls a backend-for-frontend that holds the extracted UI rules and aggregates legacy services, so web and mobile clients share the same tested logic.
Select any component
Shell-and-BFF Pattern for Screen-by-Screen Replacement: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Hosting modern front ends on each cloud
Amplify Hosting or S3 with CloudFront serves the shell. AppSync GraphQL works well as a BFF for data-dense screens that combine several legacy sources, and Cognito federates to the corporate directory.
Static Web Apps hosts the front end with built-in authentication, Front Door adds edge caching and WAF, and Entra ID SSO lets new screens open from the same desktop session as legacy clients.
Firebase Hosting or Cloud Storage with Cloud CDN serves the front end, Cloud Run hosts BFF services, and Identity Platform handles external partner users while staff federate through the corporate IdP.
Front-end choices that drive adoption
Port screens or redesign journeys
Redesign the 20% of screens that carry 80% of usage; port the long tail of admin and rarely used screens with minimal change or with low-code tools. Merging steps is where productivity comes from: in data-entry journeys we target 30-50% fewer clicks and keystrokes, measured against the legacy baseline captured during shadowing.
Micro-frontends or one SPA
Use a single SPA when one or two teams own the interface. Choose micro-frontends, using Module Federation or single-spa, only when three or more teams ship independently or legacy and new screens must coexist for more than a year. Micro-frontends add build complexity and bundle overhead that small teams rarely recover.
Keyboard-first design
For back-office and contact-centre users, preserve the old screen's function keys and tab order on day one, then improve. Data-entry staff rejecting a mouse-driven interface is the most common failure we see. Test each release with five experienced power users before wider rollout, and measure their task times, not only satisfaction.
Where UI rules move
Move validations that guard data integrity into the BFF or service layer, and repeat only lightweight checks in the browser for responsiveness. Never leave the only copy of a business rule in front-end JavaScript: it can be bypassed, and it ends up duplicated across web and mobile clients that drift apart.
Journey-by-journey UI migration
Shadowing and journey baseline
Observe users, time tasks and log keystrokes on the busiest screens.
Design system and shell
Build components, SSO and the coexistence shell with feature flags.
First journey with BFF and rules extraction
Rebuild one core journey and catalogue every rule it contains.
Pilot group rollout
Release to a pilot team behind flags and compare task times with baseline.
Next journeys and screen retirement
Ship a journey a month and retire legacy screens as usage reaches zero.
What you receive
Adoption and productivity targets
| KPI | Typical target |
|---|---|
| Task completion time on top journeys | 30-50% lower than legacy baseline |
| Time to productivity for new staff | Halved |
| WCAG 2.2 AA conformance on top journeys | 100% |
| System Usability Scale score | 75 or higher |
| Legacy screens retired | On plan each month |
Why replacement interfaces get rejected
| Risk | How NTSPL prevents it |
|---|---|
| Hidden rules lost in the rebuild | Form triggers and event handlers are scanned, and each rule is logged with a test before its screen is retired. |
| Power-user rejection | Keyboard parity and early pilots with experienced users, with a flag to fall back to old screens while issues are fixed. |
| Two systems of record during coexistence | New and old screens write through the same services, never to separate copies of data. |
| Poor performance on budget devices | Bundle budgets and testing on low-end Android phones with 3G throttling for field users. |
Low-code platform or a custom React front end for replacing legacy screens?
Use low-code platforms such as Power Apps, OutSystems, Mendix or AppSheet for internal admin screens, approval forms and long-tail screens used by a few dozen people, where speed matters more than control. Choose a custom React or Angular front end for high-volume operational screens, customer- or partner-facing journeys, offline field use, or anything needing fine control of performance and keyboard behaviour. Many programmes combine both: custom UI for the 20 screens that carry most of the work, and low-code for the remaining hundred-plus. Watch per-user licensing, which can exceed custom build cost for large external user bases.
Key facts: Legacy UI Modernization
Legacy UI Modernization in Practice
2 Legacy UI Modernization scenarios, from B2B pharma marketplace and Airport passenger services, plus related platform case studies.
B2B pharma marketplace more than doubles self-service orders with a chemist PWA
Airport services firm moves its VB6 dispatch console to tablets for 1,100 field staff
Real-estate developer handles 40x launch-day traffic on its booking portal
Regional-language OTT service halves video start time and cuts origin egress by 82%
Legacy UI Modernization: Frequently Asked Questions
How much does UI modernization cost?
Effort follows journeys, not screen counts. Redesigning a core journey of 8-15 screens with BFF APIs typically takes 6-10 weeks and INR 18-35 lakh, and the design system and shell add 3-4 weeks once. Long-tail screens ported with minimal change cost far less each.
How should new interfaces handle Indian languages and accessibility?
We build internationalisation in from the start, with Unicode fonts for Devanagari, Tamil, Telugu, Gujarati and other scripts and locale-aware lakh and crore formatting. We target WCAG 2.2 AA, which also aligns closely with the Government of India's GIGW guidelines for public-facing portals.
Can Oracle Forms be converted automatically?
Conversion tools can generate web code from Forms, but the output usually mirrors old screens and inherits their navigation problems. We use automated extraction for rules and the data model, redesign the busiest journeys, and reserve tool-based conversion for the low-use long tail.
Do all users have to switch at once?
No. The coexistence shell lets one team, branch or airport use new screens while others stay on legacy screens, controlled by feature flags. We widen the rollout group by group once task times and error rates beat the baseline, and keep a fallback flag for each group.
Will our Citrix or VDI estate go away?
Once the last legacy client screens retire, yes, and that is often a major saving. During transition, new web screens open in a normal browser while the remaining legacy screens stay published on Citrix or VDI for those who still need them.
Do we need a native mobile app or will a PWA do?
A PWA covers most field and partner needs: offline caching, camera access, an installable icon and one codebase to maintain. Choose native apps when you need deep device integration, such as Bluetooth printers or background location, or app-store distribution to consumers.