Nexaweb

Nexaweb modernization, by the people who built Nexaweb.

Nexaweb powered enterprise rich internet applications before HTML5 arrived, and platform support has since ended. Applications built on it need a route out. Vivify was founded by the team behind Nexaweb, so this is the stack we know better than any other.

Who this is for

A Nexaweb application with no vendor behind it.

This is for organisations running a Nexaweb application that still does its job on a platform that no longer has a future.

  • A Nexaweb enterprise application, often hundreds of screens, still in daily use.
  • Platform support that has ended, with no upgrade path offered.
  • A deadline attached: a browser change, a security review, or an infrastructure refresh.
  • Nobody left internally who knows how the platform works underneath.
Why now

Why Nexaweb, specifically.

This is the clearest case on the site. The platform is finished, and the applications are not.

Support has ended

There is no vendor roadmap, no patch stream, and no upgrade path. Every month the application runs is a month on software nobody maintains any more.

HTML5 did what the platform existed to do

Nexaweb solved rich browser applications before the browser could. The browser caught up. What was once a reason to adopt a platform is now simply a dependency.

The deadline usually comes from outside

These projects rarely start because somebody chose the timing. A browser change, a security review or an infrastructure refresh sets the date, which is why Nexaweb migrations tend to be fixed-deadline work.

Nobody else has read this code at scale

Vivify was founded by the team behind Nexaweb. The platform internals, the declarative screen definitions and the behavior they produce are known quantities here in a way they are nowhere else.

Your options

Three ways to deal with a Nexaweb application.

There is no supported path forward on the platform, so this is a shorter list than usual.

  1. Stay on Nexaweb

    Only defensible as a short bridge while the replacement is underway, on unsupported software.

  2. Rebuild as a web app

    Worth it when the process is changing. On hundreds of screens it is a long programme with the business logic rebuilt by hand.

  3. Automated conversion

    Read the real Nexaweb application and generate a modern HTML5 equivalent. The normal route, especially against a fixed deadline.

How we do it

Read it, model it, generate from the model.

A hand rewrite works your business rules out again from documentation and memory, which is where undocumented behavior gets lost. We carry them across from the real source instead.

01

Map the whole codebase

Code Analyzer reads every line of the Nexaweb source: every screen definition, component and server-side dependency, along with the data access and the business rules buried inside them. From that we build a model of how the application actually behaves. Gaps are surfaced, not guessed.

02

Generate from the model

Code Transformer maps the model onto a modern architecture and generates a modern web application, 90%+ automated. Generating from the model gives you an application built the way someone would build it today, instead of old workarounds in a new language. Our engineers handle the custom pieces no automated conversion can reach, with AI assistance, and check the result against your original system.

03

Prove it matches

Side-by-side testing runs the new system and the old one on the same inputs and compares what comes out. The business rules held in the model give a second, separate check that does not rely on the tests alone. Automated test coverage is built alongside the transformation.

Financial services

Hundreds of screens converted, 40% off the schedule.

A financial services firm had a large Nexaweb business application with hundreds of screens and a fixed deadline to move to HTML5 before platform support ended.

The screens were converted automatically to a modern HTML5 architecture, and the migration period came in 40% shorter than planned.

What you get

A modern HTML5 application you own outright.

Standard, conventional code

TypeScript and React by default, or Vue and similar frameworks where your standards call for it. Readable by any web developer you hire.

No platform underneath it

The result runs in any modern browser with no Nexaweb runtime, no applet and no vendor to depend on. That dependency is the thing you are paying to remove.

Code your team owns

You can host it, maintain it, and extend it yourselves, with no dependency on us to keep it running.

Screens that behave like the originals

Rich screen behavior is what Nexaweb was chosen for. It is rebuilt with standard HTML5 rather than traded away for a simpler interface.

A track record across major enterprises

Nexaweb

Common questions.

Is Nexaweb still supported?

No. Platform support has ended and there is no upgrade path on the platform itself. Applications built on it keep running, on software that is no longer maintained by anyone.

Why Vivify for Nexaweb?

Vivify was founded by the team behind Nexaweb. The platform internals and the way its screen definitions behave are known here directly, rather than reverse-engineered, which is why Nexaweb conversions run at high automation.

We have hundreds of screens. Is that a problem?

It is the normal case. We converted a financial services application spanning hundreds of screens and the migration came in 40% shorter than planned. Volume is where automated conversion earns its keep, because the per-screen cost stops being the constraint.

We have a hard deadline. Can you work to it?

Most Nexaweb projects have one, usually set by a browser change, a security review or an infrastructure refresh. The assessment produces an effort model from your actual application, so we can answer that question honestly before anyone commits to the date.

How do we know the new application behaves like the old one?

Business rules move across through a model built from your real code, rather than being re-typed by hand. We then check the result two ways: side-by-side testing on the same inputs, and the business rules held in the model as a separate check.

Where does a Nexaweb migration start?

Usually with the free assessment: a complete dependency map, risk scoring, an effort model and a costed migration plan, produced from your own application. Against a fixed deadline it is the fastest way to find out whether the date is achievable.

Find out what your Nexaweb application contains, and whether your deadline is achievable.

The assessment is free and built from your own source code. If you would rather see output first, we can run a paid proof of concept on a representative slice of the application.