Specialized consulting for the incremental modernization of mission-critical IBM i (AS/400) systems: API enablement, data integration, and the structured evolution of legacy RPG. Stability preserved. Capability extended.
C CUSTNO CHAIN CUSTMAST 99
C *IN99 IFEQ '0'
C MOVEL CUSNAM NAME
C Z-ADD CUSBAL BALANCE
C EXSR FMTOUT
C ENDIF
C SETON LR
F3=Exit F5=Refresh F12=Cancel
Fixed-format RPG. In production for decades.
Undocumented. Irreplaceable. Still correct.
**free // Customer inquiry: same business rule, // now readable, testable, and API-ready. exec sql select cus_name, cus_balance into :name, :balance from custmast where cus_id = :custNo; if sqlcode = 0; formatOutput(name : balance); endif; return;
Same business logic. Same platform. A codebase the next generation can maintain.
Incremental modernization preserves the operational stability of the IBM i transactional core while progressively integrating it with modern enterprise platforms. Nothing is rewritten for the sake of rewriting. Nothing proven is put at risk. Hover over each service to see how it works.
Design and engineering of REST and SOAP layers, secure authentication architectures, and integration gateways that connect modern web, mobile, and cloud applications to the stable IBM i transactional core, without modifying proven business logic.
Architectures connecting DB2 for i with contemporary ERP, e-commerce, and cloud platforms, preserving transactional consistency under high-concurrency loads. Includes the migration of legacy DDS structures to modern DDL.
Structured migration of fixed-format RPG codebases to modern, fully free-form, well-documented SQLRPGLE, extending the operational life of mission-critical systems beyond the current specialist generation.
A six-phase engagement cycle that integrates AI-assisted code analysis, documentation extraction, and refactoring acceleration under non-delegable human architectural supervision.
AI-assisted scanning and documentation of the existing codebase: program dependencies, undocumented business rules, and technical debt.
Human-led design of the target architecture: integration boundaries, data-flow contracts, security. Performed exclusively by a senior architect, without AI delegation.
AI-assisted code generation and refactoring under continuous human review, using tools adapted for RPG and legacy source analysis.
Structured human review of all AI-assisted output against the architectural design. Anything below production-grade standards is rejected and reworked.
Controlled migration to production under formal change-management discipline.
Documentation of all changes and structured training of the client's internal team to maintain the modernized environment independently.
AI tooling accelerates discovery and implementation: analysis that historically required months of manual reading can now be completed in weeks. What it cannot do is take responsibility. Architectural decisions, business-rule integrity, and production stability remain the responsibility of the senior engineer at every phase. In systems that process a company's daily revenue, acceleration without accountable supervision is not modernization. It is risk.
iEvolution Systems is a specialized IBM i modernization consulting practice being established in the Dallas-Fort Worth Metroplex, Texas, led by a backend engineering specialist with more than sixteen years of continuous IBM i practice in ILE RPG, RPGLE, SQLRPGLE, CL, COBOL, and DB2 for i.
That experience was built inside enterprise operations, not around them: coordinating software development and solutions for the technology operations of a multinational retail group, supporting mission-critical commercial systems across six Latin American countries and a United States distribution operation, with direct responsibility for platforms processing 4.5 million fiscal transactions annually.
The practice serves organizations whose core operations run on IBM i, with particular focus on banking, financial services, insurance, retail, manufacturing, and logistics in Texas and adjacent United States markets.
Computer engineer and backend engineering specialist with more than sixteen years of continuous IBM i practice in ILE RPG, RPGLE, SQLRPGLE, CL, COBOL, and DB2 for i, built inside enterprise production environments: first in high-maturity banking software delivery, then coordinating software development and solutions for the technology operations of a multinational retail group.
His work spans the full modernization arc this practice delivers: API layers over stable transactional cores, high-concurrency data integration between DB2 for i and modern platforms, and the structured evolution of fixed-format RPG into documented free-form SQLRPGLE. Active member of COMMON and Co-Webmaster of the IEEE Educational Activities Committee, Colombia Section.
Short technical notes on the decisions that keep IBM i cores stable while everything around them changes.
Most IBM i systems in production today are not old code that survived by accident. They are the accumulated, tested encoding of how a business actually operates: pricing exceptions, regulatory edge cases, reconciliation logic that no requirements document ever captured. A rip-and-replace project must rediscover all of it under deadline pressure, which is why large-scale replacements of stable transactional cores so often run over budget, over schedule, or into production incidents.
Incremental modernization inverts the risk profile. The proven core keeps running and keeps processing revenue. Around it, three moves are sequenced: an API layer that exposes core functions to modern applications without touching them, data integration that lets contemporary platforms consume DB2 for i data with transactional consistency, and the progressive conversion of the codebase itself into maintainable free-form SQLRPGLE. Each step is independently valuable, independently testable, and reversible. The business never bets its daily operation on a single cutover date.
The practical test is simple: if a modernization plan requires the proven system to stop before the new one is trusted, the plan is carrying more risk than the technology problem it claims to solve.
Many IBM i databases still describe their physical and logical files through DDS, the definition language of an earlier era. DDS did its job for decades, but it cannot express what a modern relational engine can enforce: referential integrity constraints, identity columns, richer data types, and the metadata that integration tools and query optimizers depend on.
Migrating those definitions to SQL DDL changes none of the business logic and all of the guarantees. Integrity rules that today live scattered across programs, or exist only in the discipline of the people who maintain them, move into the database engine itself, where they are enforced for every program, every interface, and every future developer, automatically. Downstream integration also gets simpler: modern ERP, analytics, and cloud platforms speak SQL natively, and a DDL-defined database meets them on their own terms.
Done correctly, the migration is staged, surrogate-tested, and transparent to running applications. Users see nothing. The database becomes something it never was under DDS: self-defending.
The single slowest phase of any IBM i modernization has always been discovery: reading thousands of undocumented fixed-format programs to reconstruct the business rules buried inside them. AI-assisted code analysis compresses that phase dramatically. Work that historically required months of manual reading can now be completed in weeks, with the model surfacing candidate rules, dependencies between programs and files, and dead code paths for human review.
The word that matters is candidate. A language model does not know which exception handler encodes a regulatory requirement and which one papers over a bug from 2004. It does not carry responsibility for a payroll run, a settlement file, or a fiscal transaction. In this industry, skills shortage is now the leading operational concern of IBM i organizations, and it is tempting to read AI as the replacement for the specialists who are retiring. It is not. It is the tool that lets one accountable architect do the discovery work that used to require a team, while architectural decisions, business-rule integrity, and production stability remain human responsibilities at every phase.
AI shortens the road. The architect still answers for where it leads.
Industry context: Fortra, "2026 IBM i Marketplace Survey Results." Available at: fortra.com/resources/guides/ibm-i-marketplace-survey-results
Active member of COMMON, the principal North American professional association of IBM i practitioners, including participation in its conferences and technical community.
Co-Webmaster of the IEEE Educational Activities Committee, Colombia Section, contributing to the communication infrastructure of the educational arm of the world's largest professional engineering association.
A first conversation is technical, specific, and without obligation: your platform, your integration goals, and whether incremental modernization fits your operation.