Model-driven development
The new system is generated from the model, so your rules move across as they are. Nobody re-types them, and no AI is asked to work out what they were meant to do, so they cannot quietly come out meaning something different.
How it works
Parse. Transform. Modern app.
Modernization at Vivify is model-driven and 90%+ automated. We read your system, build a model of what it does, generate the modern version from that model, and prove the result behaves like the original.
What model-driven means
We read the code. The model does the rest.
Parsing means our analyzer reads every line of your source code and works out what the system actually does: every screen, every piece of data, every business rule. All of it goes into a model. The new application is then generated from that model.
The second half is where it pays off. A line-for-line conversion drags thirty years of workarounds and dead ends into the new system, and you end up maintaining the same old application written in something newer. Generating from the model gives you an application built the way someone would build it today.
It is also why the output stays compact. Ask an AI to write the code and it tends to produce far more of it than the job needs, which your team then has to read and maintain for years. The model holds what your system actually does, and that is what gets built.
- Your legacy codeevery screen, rule and table
- Parsewe read every line
- The modelwhat your system does
- Transformgenerated, not translated
- Modern appclean, standard code you own
Why it comes out correct
Three checks, and what each one actually proves.
Every evaluation arrives at the same question: how does anyone know the new system still does what the old one did. We answer it three ways. Two of the three rest on the same thing, the accuracy of the model, so it is worth being precise about which is which.
Side-by-side automated testing
The new system and the old one are run on the same inputs and what comes out is compared automatically. The test libraries are built from your own test plans, so the comparison covers the behavior your business actually depends on rather than a generic suite.
Business rules held in the model
The model holds your business rules explicitly, so the generated system can be checked against them rule by rule. This catches generation errors. It shares a dependency with the first check: if the model misread the source, both inherit that error, which is why the comparison against the running system matters.
Generate it from your source, check it against the rules, then prove it against the system you are actually running.
Where it can go wrong
What happens when the model is wrong.
The model is read from your source by software, and software has limits. Treating that as a thing to manage, rather than a thing to promise away, is most of why these projects land.
The model is reconciled against the source
Before anything is generated, what the model contains is checked back against the codebase it came from: screens, programs, rules and data paths are counted and reconciled. Anything the parser could not resolve is listed as an open item rather than dropped quietly.
Unsupported constructs are named, not approximated
Every real codebase contains things automated conversion does not cover. They come out of the analysis as named items with effort attached, which is what the 90%+ automation figure is measured against. Our engineers implement them, and they are the part of the estimate most worth scrutinising.
Mismatches are traced to a cause
When side-by-side testing shows a difference, it is investigated until the cause is known: a generation defect, a gap in the model, or the old system doing something nobody intended. The third case is common in a system this old, and it is a decision for you rather than for us.
Acceptance stays with your business
The comparison runs against your own test plans, and the people who own those processes accept the result. Automation does not replace business acceptance. It changes it from rebuilding the specification to reviewing evidence.
Parse your application into a model
Code Analyzer reads every line of your source code: screens, navigation, data access, and the business rules buried inside them. From that we build a model of how your application actually behaves. A tool does the reading, so nothing depends on a person working through it by hand.
- Full inventory of screens, components, and data flows
- Business rules captured as a model, not as notes
- Gaps in the old code are surfaced, never silently dropped
Transform the model to a modern architecture
Code Transformer maps the model onto a modern architecture and generates the new application from it. A line-for-line translation would drag thirty years of workarounds into the new system; generating from the model gives you an application built the way someone would build it today. 90%+ of the work is automated. Our engineers handle the custom pieces no automated conversion can reach, with AI assistance, and check the result against your original system.
- Business behavior carried across by design
- AI helps where the old code is unclear; results checked against the original
- Standard code, with no proprietary runtime underneath it
- Consistent patterns across the whole application
Deliver a modern app you own
You receive a responsive, maintainable application your own team can read, run, and extend on current frameworks. Because the output is standard code, you can host and maintain it entirely yourselves.
- Responsive across web, tablet, and mobile
- Clean code your engineers can own from day one
- Automated test coverage built alongside the transformation
- Portable, with no dependency on us to keep it running
Where AI fits, and where it does not.
Your new system is not written by an AI. It is built from the model by a fixed set of rules. Run the same code through twice and you get the same result twice.
The alternative, which you will hear a lot of in the next year, is to point an AI at old code and ask it what the code does. It will always give you an answer, and it sounds just as sure when it is wrong as when it is right. A rule that came across wrong does not announce itself. It shows up months later, in a report that does not balance or a customer who gets the wrong number, long after the old system has been switched off.
Reading code and understanding it are different jobs. Every one of these languages has behavior that only becomes obvious once it has caught you: how a PowerBuilder DataWindow resolves an update, what a COBOL level-88 condition actually covers, where a VB6 variant quietly changes type. Our engineers have been working in them since 2004, across more than 200 modernization projects, and the analyzer is built out of that experience. Nobody here is seeing your source language for the first time.
We do use AI where it saves real time: the custom work no automated conversion can handle, building tests, and filling gaps where the old code is incomplete or unclear. Everything it produces is checked against your existing system before it ships.
Included in the engagement
Test automation is part of the modernization.
A modernized system has to prove it behaves like the original. Share your test plans, or even outlines of them, and we build automation libraries for the tests that exist today and prepare for the ones that will exist tomorrow. AI helps us build that coverage quickly and keep it thorough.
- Automation libraries built from your existing test plans
- Regression coverage that verifies old and new behave the same
- A test foundation your team keeps extending after handover
Why this approach
Built to remove the risk from modernization.
Lower risk than a rewrite
A hand rewrite re-implements years of business rules from scratch and hopes nothing is lost. Here the rules are read out of your real code and carried through automatically, so the behavior is preserved by the mechanism itself.
Faster, more predictable
Automating the bulk of the conversion compresses timelines from years to months, with far less variance, because nobody is hand-coding every screen.
No vendor lock-in
The deliverable is standard TypeScript / React, or Vue and similar frameworks where your standards call for it. There is no Vivify runtime sitting under your application and no license you must keep paying to run your own software.
Proven at enterprise scale
The same approach has modernized systems for major enterprises since 2004, across more than 200 projects. See the organizations we have worked with.
The best way to understand it is to see it on your code.
A proof of concept runs this process on a representative module of your real application, so you can read the code you would own. If you would rather start with what is in the system and what moving it costs, the assessment is free.