RPG applications on IBM i still run distribution, manufacturing and trading companies around the world. The platform is not the problem. We model the RPG programs and display files from the real source and generate a modern web application, with the rules carried across.
This is for companies whose IBM i application is reliable and fast, and completely impossible to put in front of a customer or a new hire.
IBM i has a published roadmap and is not going anywhere. The application on top of it is the issue.
IBM continues to invest in IBM i, so this is not a platform rescue. It is that a 5250 green-screen application cannot be given to a customer, a field user or a graduate hire, no matter how well it runs.
RPG expertise, particularly for older fixed-format code, sits with people near the end of their careers. Replacing them means hiring for a skill almost nobody is learning, which gets more expensive every year.
Wrapping green screens in a web front end gives you a nicer surface over exactly the same tangle. The business rules stay where they are, the maintenance problem stays where it is, and you now have two things to maintain.
Logic in an IBM i application is spread across programs, display files, service programs and database triggers. That is precisely the shape of problem that analysis solves and interviews do not.
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.
Code Analyzer reads every line of the RPG source: every program, display file, service program and database 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.
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.
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.
TypeScript and React by default, or Vue and similar frameworks where your standards call for it. Readable by any web developer you hire.
There is no Vivify runtime under your application and no license you must keep paying to run your own software.
You can host it, maintain it, and extend it yourselves, with no dependency on us to keep it running.
A web application that works across desktop, tablet, and mobile instead of a Windows-only install.
A track record across major enterprises
No. Modernizing the application and moving off the platform are separate decisions. Plenty of organisations keep IBM i and the Db2 data where they are, and change the application that sits on top.
Real IBM i applications are usually a mix of RPG III, RPG IV and free-format accumulated over decades, often with CL and embedded SQL alongside. The analysis reads what is actually there rather than what the standards document says should be there.
Refacing puts a web interface over the existing 5250 application, so the RPG and the maintenance problem both stay exactly as they are. Conversion generates a new application from a model of the real source, which is why the hiring problem actually goes away.
It can stay. Converting the application does not require moving the database, and keeping the data in place is often what makes a staged migration possible while the business keeps running.
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.
Usually with the free assessment: a complete dependency map, risk scoring, an effort model and a costed migration plan, produced from your own source code.
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.