Modernize IBM i without taking on a new dependency.
Your RPG keeps the business rules. Your data stays in Db2. We build the browser layer over the top, and you choose where it runs, what it's built in, and you keep the source.
CUS200 CUSTOMER INQUIRY 14:22:07 Customer . . . 0041827 Name . . . . . MERIDIAN BUILDING SUPPLY Address . . . UNIT 4 CARLTON IND EST City . . . . . SHEFFIELD Post code . . S9 2LR Terms . . . . 30 Currency . . GBP Credit limit . 0045000.00 Balance . . . 0031204.66 Status . . . . A F3=Exit F5=Refresh F12=Cancel
Meridian Building Supply
Customer 0041827 · Active
- Address
- Unit 4 Carlton Ind Est, Sheffield S9 2LR
- Terms
- 30 days
- Credit limit
- £45,000.00
- Balance
- £31,204.66
- Available
- £13,795.34
Same file. Same business rules. Same machine.
The platform isn't the problem. The interface is.
IBM i runs the business and does it well. But the green screen now blocks things the business needs: customer self-service, supplier access, mobile, MFA, an audit trail. And the people who understand the code are retiring.
Every vendor who calls has the same answer: leave the platform. That answer is expensive, slow, and throws away thirty years of business logic that exists nowhere else.
Three hosting models. One architecture.
You are not asked to settle your infrastructure strategy before you start modernizing.
| On the box | Beside the box | In the cloud | |
|---|---|---|---|
| Runs in | Your existing IBM i partition, in PASE | A Linux partition on the same Power hardware | A cloud VM |
| Db2 access | Local, and never crosses a network | Internal virtual networking between partitions | Secured connection to on-premise Db2 |
| New licensing | None | Linux partition | Cloud subscription |
| Choose when | Data cannot leave the machine | You want standard Linux operations, still on your own hardware | A cloud-first decision has already been taken |
The web tier should match your team.
We fix the architecture, not the technology. The boundary between the web tier and your business logic is a stored procedure, which means what sits above it is genuinely interchangeable.
We'd normally maintain it for you. That's the Run engagement, and most of this work continues that way. But taking it in-house should always stay your option, and if a .NET shop is handed a Python application that option quietly disappears. That is exactly the dependency you were trying to get rid of.
No runtime licence. Ever.
Most modernization products charge for a runtime, forever. Stop paying and the interface stops working.
We deliver the source, built on open components. There is nothing to keep paying for, and nothing that stops working if we do.
- Source delivered: no proprietary runtime, no per-seat licence
- SSO and MFA where the green screen can't offer it
- Role-based access control and full audit logging
- Connection-pooled Db2 access, load-tested at 500 concurrent users
- Hardened against the OWASP Top 10, built to ASVS Level 2
We don't rewrite business rules that already work.
The modern layer handles presentation, navigation, authentication and formatting. Every business rule (pricing, credit, availability, tax, allocation) stays in RPG service programs, reached through stored-procedure wrappers.
One set of rules. One source of truth. The thing that goes wrong in most modernization projects, designed out from the start.
This is not affection for RPG. Rewriting working business rules is the highest-risk, lowest-return activity in any modernization programme. A year of effort to arrive back where you already were, if it goes well. And because the stored procedure is the boundary, those rules can be replaced later, one service at a time, whenever there is an actual reason to. That is a very different proposition from rewriting all of them at once as the price of starting.
Start with the lowest risk. Go as far as you want.
You don't sign up for a transformation programme. Each phase ships and runs before the next is discussed.
Most customers see the value by the end of Phase 1, and decide about Phase 4 much later.