For 30+ years, SYNON delivered something valuable: fast application development for IBM i. If you built applications with SYNON, you made a pragmatic choice for its time.
But SYNON stopped evolving. And now you’re stuck with an aging CASE tool, generated code that resists modern DevOps, and a shrinking pool of developers who understand it—or want to.
Here’s what most SYNON shops tell us:
“We’re trapped. The code works, so we can’t rip it out. But we can’t modernize it, and we can’t hire people who know SYNON. We’re stuck maintaining this forever.”
That assessment is wrong.
There’s a practical exit ramp. And it doesn’t require leaving the platform that’s been reliable for decades.
Why SYNON Became a Lock-In
SYNON was brilliant at what it did: abstract the complexity of IBM i development into a model-driven CASE tool. Developers built models and SYNON generated RPG code. The problem was that the generated code became a black box. SYNON-generated RPG was optimized for machine generation, not human understanding—field names were cryptic, logic was densely packed, comments were sparse or nonexistent. When you needed to fix a bug or add a feature, you had two uncomfortable options: go back to the SYNON model, modify it, and regenerate everything, or hand-edit the generated code and risk breaking the regeneration process. Both were painful. Most shops chose option 3: leave it alone and route around the problem.
That strategy worked until two things happened simultaneously. SYNON specialists started retiring, taking with them the knowledge of how your specific applications work—the unwritten rules, the business logic baked into those models. At the same time, modern DevOps toolchains (Git, Jenkins, Jira, Docker, API gateways) started expecting code that fits into a pipeline. SYNON-generated code doesn’t. Your SYNON applications became islands—fast to maintain within their own environment, impossible to integrate with modern infrastructure.
Most shops faced an unappealing decision: rip out SYNON and rebuild in a modern language like Java, Python, or .NET, or accept permanent technical debt on this corner of the stack. Neither option looked good.
What Changed: Automated Conversion Tools
The breakthrough is automated SYNON-to-RPG Free conversion. Modern tools can now:
- Read your SYNON models and generated code
- Extract the business logic and data structure
- Generate clean, human-readable RPG Free Form code that preserves 100% of your business logic
- Optionally modernize your database schema from the legacy SYNON model into a rich, relational DB2/SQL structure
The resulting code isn’t auto-generated gibberish. It’s clean, indented, self-documenting RPG Free Form that a developer unfamiliar with SYNON can understand and maintain.
Real-world example: A global logistics company (GEODIS) converted a major SYNON application to RPG Free Form. Result: 35% performance improvement, a complete CI/CD pipeline integration, and code that junior developers could actually work with.
No magic. No AI. Just mature conversion technology that actually works.
Why This Matters Now
Three reasons this is urgent in 2026:
Skills availability. SYNON expertise is at an all-time low. If your SYNON specialists retire before you have a modernization plan, you’re in crisis mode.
Platform evolution. IBM i itself is evolving—better integration with open-source tools, modern API frameworks, cloud connectivity. SYNON applications can’t leverage any of these because they’re locked in a 1990s architecture.
Talent acquisition. Younger developers will learn RPG Free Form. They won’t learn SYNON. If you want to attract next-gen talent, you need code they can understand.
How Conversion Actually Works
The typical flow is structured and methodical. In the assessment phase (1–2 weeks), you inventory your SYNON applications, document the data model and business logic, and identify which applications are good conversion candidates based on complexity, maintenance cost, or operational criticality. A pilot conversion follows (2–4 weeks), where you select one mid-size SYNON application, run the conversion tooling to generate RPG Free Form code, and validate functionality, performance, and error handling. That pilot teaches you what needs fine-tuning.
Code review and optimization (2–3 weeks) involves reviewing the converted code for readability and adherence to your standards, optimizing database schemas if you’re moving to full SQL/DDL, testing against your business logic, and updating integrations or batch jobs. Cutover (1 week) means deploying to production, monitoring for regressions, and keeping the SYNON version available as a fallback for 30 days while you verify stability. Finally, you scale—applying lessons learned to remaining applications, building a modern CI/CD pipeline for the newly converted code, and planning incremental evolution.
The entire process for one moderate-sized SYNON application typically takes 6–10 weeks from start to full production stability.
The Business Case
Let’s be concrete. A mid-market company with three SYNON applications:
Current state (SYNON):
- 2 FTE specialized in SYNON maintenance
- $150,000/year in SYNON expertise
- Limited ability to integrate with modern systems
- Generational knowledge risk (retirement of key experts)
- High cost of adding new features
Post-conversion (RPG Free):
- 1.5 FTE can handle all three applications (reduced complexity)
- $80,000/year in standard RPG expertise
- Full integration with Git, CI/CD, modern API layers
- Code is self-documenting and maintainable by any RPG developer
- 20–30% reduction in maintenance time (per industry benchmarks)
ROI: $70,000–$100,000 annually in reduced maintenance costs, plus eliminated generational knowledge risk.
The conversion itself costs $30,000–$60,000 depending on application complexity. Payback period: 4–8 months.
What Doesn’t Change
I’ll be clear: this is not a platform migration. You’re not leaving IBM i. You’re not rebuilding your application logic. You’re not accepting new technical debt.
What happens:
- Your SYNON-generated code becomes readable RPG Free Form code
- Your database schema optionally modernizes to full SQL/DDL
- Your business logic stays exactly the same
- Your application performance typically improves (30–40% in most cases)
- Your code integrates with modern development toolchains
You’re staying on the most reliable, secure, and cost-effective platform for your business. You’re just removing the lock-in and positioning yourself for the next 30 years.
Common Concerns (Addressed)
The question “won’t this break something” has a straightforward answer: the conversion tools preserve business logic at a byte level, so if the converted code is tested against your existing test suite, it passes. Risk is low when the process is done properly. Some worry about needing to go back to SYNON—you won’t, because the converted code is better. Your SYNON version still exists if you need it as a fallback, but you’ll never choose to use it once the modern RPG is running. People also wonder whether their team will be able to maintain the converted code—the answer is yes, because any RPG developer can read and maintain RPG Free Form. That’s the entire point of the conversion. On timeline: a typical SYNON application takes 6–10 weeks from assessment to production. You’re not on hold during this time; other applications keep running normally.
The Decision Point
If you’re still running SYNON applications, you have three paths:
- Do nothing. Maintain SYNON as-is until the specialists retire, then deal with crisis mode.
- Rebuild from scratch. Abandon SYNON and rewrite in a modern language. High cost, high risk, long timeline.
- Modernize the code. Convert to RPG Free Form, preserve the business logic, gain maintainability and modern toolchain integration.
Path 3 is the one that delivers business value without betting the company.
If you’re running SYNON applications and wondering whether modernization makes sense for your situation, let’s talk. We’ll help you assess your applications, understand the opportunity, and plan a conversion approach that fits your operation.