Your IBM i runs the business — and it isn't going anywhere. What's going somewhere is the bench of people who can change it. Marcus, Kinetech's AI Mendix developer, reads your source members, display files, and Db2 catalogs over a single read-only connection and rebuilds the interactive layer as modern Mendix applications over the same data — while your RPG core keeps doing what it does best.
01 · The clock
Let's start by agreeing with your ops team: IBM i is not a dying platform. Power11 shipped in July 2025, IBM i 7.6 in April 2025, and IBM's published roadmap runs into the 2030s. In Fortra's 2026 IBM i Marketplace Survey, 95% of shops say the platform delivers better ROI than their other servers. The problem isn't the machine.
02 · The differentiator
An IBM i estate is unusually machine-readable — the whole application layer is declarative, plain-text, and retrievable over one read-only ODBC or FTP connection. No agents installed, no production risk, no workshops asking users to remember how a 1998 screen behaves. The system says what it does; Marcus reads it.
| IBM i artifact | What Marcus extracts | Where it lands in Mendix |
|---|---|---|
| Source members (QRPGLESRC, QCLSRC…) | Full program and CL inventory with a call graph, via the QSYS2 catalogs — one read-only connection | The estate map: what exists, what calls what, what's actually used |
| Display files (DSPF DDS) | Every field, position, length, edit code, indicator-conditioned visibility, and function-key mapping — a complete screen spec | Pages, with the original screen's intent preserved |
| Subfiles (SFL/SFLCTL) | List layout, columns, selection options, paging behavior | Data Grid 2 — subfiles map almost one-to-one to a modern data grid |
| Physical & logical files (DDS / SQL catalogs) | Tables, columns, keys, and the logical-file views that encode access paths | Domain model — entities, associations, indexes |
| RPG & CL logic | Validation rules, calculations, and flow — extracted as business rules for human review. Honestly: fixed-format RPG III with indicator logic is the hard part, and it's surfaced, not hidden | Microflows — or calls to the original program where the logic should stay put |
| Printer files (PRTF / O-specs) | Print and report inventory | Keep operational print as-is; move human-read reports to PDF and dashboards |
Why this matters: the incumbent tools either reface screens or transpile code. What hasn't existed is a developer that reads the DDS and RPG and then does an evidence-gated rebuild — tested per role, documented, delivered as standard Mendix your mainstream developers can extend. That's Marcus.
03 · How a migration runs
The architecture is deliberately conservative: your RPG batch engine, night runs, and Db2 files stay exactly where they are. Marcus rebuilds the interactive layer — screens, inquiries, approvals, departmental apps — as Mendix over the same data, cluster by cluster.
The same four approval gates that govern every Marcus engagement govern each screen cluster — held by you:
The extracted spec of each screen cluster — fields, rules, who uses it, what stays green-screen — approved before a line of the model is written.
Menu and object authority translated to Mendix roles, presented in plain English for sign-off — including the write path back into Db2.
Modern design directions presented before pages are generated. Your warehouse scanner UI and your CFO's dashboard don't have to look like 1988.
Each cluster reaches you only after all quality gates pass; it cuts over only when you accept it — with the old screen still available behind it.
04 · The date
Here is the commitment we will put in writing. The assessment does not end with a range — it ends with a date, sized from your actual extracted complexity. Miss that date and the assessment fee comes back. We can promise a date because we never quote a calendar before reading your source.
The assessment names the date. Miss it, and the assessment fee comes back.
That is a real term, not a slide. It is affordable to us for one reason: the clock below starts only when a complete artifact pack is in our hands, and it pauses only for your own approval gates.
| One function set surrounded (the core stays) | Complete artifact pack → UAT-ready |
|---|---|
| Compact — ≤30 RPG programs, ≤20 display files, one subsystem of work | 3–4 weeks |
| Departmental — 30–120 programs, 20–60 display files, 2–5 touchpoints into the core | ~45 days typical |
| Load-bearing — 120+ programs, RPG III fixed-format, heavy CL orchestration, multi-library | 10–16 weeks |
| Each further function set on the same core | 30–40% faster |
Sizing model, not a price list — the assessment reads your actual source and returns one date. Bands assume a single rebuild boundary agreed at the scope gate.
The date is only honest if the inputs are complete, so here is the whole list up front. Nothing on it is unusual, and most of it exists already.
Three approval gates are yours: scope, permission ratification, design sign-off. We answer each within three business days. Time beyond that on your side moves the date by exactly that much — and nothing else does.
Production cutover on your change calendar. SSO and network provisioning by your IT. Third-party licenses or vendor contracts we don't control. Remediation of source-data quality problems the assessment flagged. Anything added after the scope gate.
Functional parity against the approved specification, running on your migrated data in a parallel environment, with production security enforced and tested per role, all nine quality gates green, and documentation published. Your users click through it.
The reason this has a date at all is that we are not rewriting your core. The IBM i keeps running the system of record; Marcus builds the modern application around it and calls in through jt400 or Integrated Web Services. That makes the unit of work a function set rather than a system, which is what makes it schedulable at all. What moves the date is undocumented adopted authority, fixed-format RPG III that has to be read before it can be scored, and business rules living in CL orchestration rather than in a program.
05 · Why Mendix
Every IBM i modernization path gets judged by one question: who maintains the result in 2032?
06 · Straight talk
| Area | The honest position |
|---|---|
| Batch & night runs | Untouched, by design. Job schedules, overnight processing, and the programs behind them stay exactly as they are. Mendix writes through the same files and the same wrapped RPG programs — the batch never knows anything changed. |
| Heads-down power users | For your five fastest keyers, a tuned 5250 screen is genuinely quick — keep it for them. The rebuild targets everyone else: occasional users, new hires, warehouse and mobile flows, and anything customer-facing, where the green screen is a training and error tax. |
| Operational print | PRTF-driven labels, pick tickets, and forms keep printing exactly as today. Human-read reports move to PDF and dashboards incrementally — not as a big bang. |
| Old RPG logic | Fixed-format RPG III with indicator soup is the hardest artifact in this estate. Marcus extracts candidate rules and flags low-confidence passages for human review — extraction produces a spec you approve, never silently transpiled code. |
| Security architecture | Data read over JDBC sits outside Mendix's entity-level security, so the design pattern matters: constrained read paths, writes through wrapped RPG or stored procedures. The architecture is presented at the permission gate — you ratify it before anything is built. |
| References | We'll be direct: there is no public Mendix-on-IBM-i flagship story yet — from us or anyone. That's why the entry offer proves the approach on your data, with a working rebuilt screen and published evidence, before you commit to anything larger. |
07 · Quality & security
Watch real build evidence land on the live Build Console, and see the delivery lifecycle at our interactive explainer.
08 · Engagement & pricing
A read-only pull of your source members and catalogs, then an automated inventory: programs, screens, files, call graph, a screen-by-screen complexity map — and one real subfile screen rebuilt as a working Mendix page against your Db2 data, as proof.
Credited toward onboarding if you proceed.
Each cluster quoted from its actual extracted complexity — not a day-rate guess. Built, tested per role, documented, and delivered through the approval gates with published evidence.
Best for a first wave: one department's screens, end to end.
For large estates: a Marcus instance works your modernization backlog continuously. Priced on what the work is, how many lanes run in parallel, and how fast you need it — always with Kinetech engineer review and an escalation SLA.
Bring your own Claude access: roughly 15–25% off the monthly.
Every figure here is an indicative range; your actual range is confirmed in writing before anything is charged. On bundled plans, heavy build months may incur metered usage beyond the included allowance; your quote states the allowance plainly. Your applications, models, and repositories are contractually yours.
09 · The questions you should ask
For a tuned heads-down keyer, they often are — and we won't take that screen away from them. The rebuild targets everyone the green screen taxes: the manager who checks one inquiry a week and needs a cheat sheet, the new hire who takes months to learn the F-key map, the warehouse floor that deserves a scanner-friendly mobile flow, and the customers and vendors who could self-serve instead of calling. Keep 5250 where it wins; retire it where it costs you.
Nothing — that's the architecture, not a promise. The batch programs, job schedules, and files stay untouched; Mendix reads the same Db2 data and writes through your existing programs exposed as services. If a rebuilt screen were to disturb the night run, our own permission gate would have failed first — the write path is presented for your ratification before anything is built.
Agreed — loudly. IBM i has a roadmap into the 2030s and your ops team is right to trust it. The risk isn't the platform; it's that 69% of shops now rank skills as their top concern — first time in nine years it beat security (Fortra's 2026 survey). Every screen change waits on a shrinking bench. A Mendix layer lets mainstream developers carry the interactive workload while your RPG experts focus on the core only they can maintain.
If cosmetics are the whole requirement, refacing wins on price and we'll tell you so in the assessment. But refacing leaves the same RPG underneath, maintained by the same scarce people — you've repainted the queue, not shortened it. It also can't give you what departments actually ask for next: workflow, mobile, integrations, new fields. A rebuilt Mendix app can, and mainstream developers can do it.
The conversion ecosystem's own track record answers this: the output is widely described as procedural RPG idioms in Java syntax — code your Java developers won't own. We take the opposite approach: Marcus extracts a human-approved specification from the DDS and RPG, and then builds a native Mendix application from it. Where logic genuinely belongs in RPG — pricing engines, batch — it stays there and gets called as a service, not converted.
Operational print — labels, pick tickets, regulated forms — keeps running on your printer files exactly as today. Reports that humans read on paper because 1995 offered nothing better become PDFs and dashboards, incrementally, with the print path retired only when its consumers have moved. Print fidelity is scoped explicitly in the assessment, never hand-waved.
There's no public flagship story — from us or anyone — and we'd rather tell you that than imply otherwise. Two things make this a smaller leap than it sounds: every technical ingredient is standard and proven (JDBC into Db2 for i is the ordinary Java path; REST-wrapping RPG via Integrated Web Services is IBM's own built-in mechanism), and the Estate Scan is designed to retire the question with evidence — a real screen of yours, rebuilt and running against your data, before you commit to anything more.
10 · Next step
That's the entire ask: a read-only profile and a day. The Estate Scan returns your program and screen inventory, a complexity map, and one of your own subfile screens rebuilt as a working Mendix page against your Db2 data — with the evidence published. Judge the approach on your estate, not on a slide.
Marc Lehane · Solutions Architect / CTO, Kinetech · [email protected]
Kinetech Cloud · San Antonio, TX · How we deliver · Live Build Console
You are reading Your platform — deeper detail on step 4, Why now?.
That is the pressure. What it costs to answer it is not one number — three things move it.