Strumenta 
Let’s be clear: Changing technology for the sake of change is pointless—it’s just a status game. If that’s your motivation, you’d be better off spending your money on a nice car. However, there are situations where outdated technology actively holds back your business, and in those cases, modernization is not an IT decision—it’s a business decision.
You should consider modernizing when your ERP or other core systems slow down your ability to act. If every time you have a new idea, your software team tells you it can’t be done, or that it’s too risky, or that it will take six months while your market opportunity lasts only a few weeks, you have a problem. Eventually, you’ll stop trying, and when that happens, the writing is on the wall for your business.
On the other hand, if your technology is ridiculously outdated but isn’t limiting your ability to operate or innovate, who cares? You can ignore it for now. But the moment it starts restricting your business, it becomes a business problem—not just a technical one. And depending on how much you care about the survival and competitiveness of your company, you should take action.
In this article, we explain how you can do that.
What is the situation out there?
Being a consultant is like being a priest: you end up knowing a lot of the sins committed in your village. So I can tell you: there are a number of mid-sized companies (50–500 employees) that have an RPG system at the heart of their operations. And while it was great back in the day, now the number is going down: some companies close shop, others bite the bullet and move to a new system (more or less painfully). It may feel like being among the last survivors: you turn around and notice there is one less of us left.
While you would like to think about something else, the fact is that those systems are hard to change, and finding people who know how to work on them is a nightmare. They also happen to be expensive, but that is just the cherry on top. You keep patching things up, hoping to see another day. One day, you are sure, we will get the time to think about a more permanent solution.
A simple metric (that you may not like)
Modernization shouldn’t be “IT for IT’s sake” – it’s not about chasing trends or keeping up appearances. It has to serve your business. The real question: is your tech helping you move forward, or is it just something you keep pouring money into because you don’t know how to escape it?
If you’re running on an old COBOL or RPG system, chances are 60–80% of your IT budget is just keeping the lights on. That’s like spending most of your paycheck every month just to cover interest on old debt—you’re not getting ahead, you’re just stuck. And at some point, skipping town seems a tempting option. That’s a dangerous place to be.
Tech should be an advantage, not a financial black hole. If you’re only maintaining what you already have, you’re playing defense instead of offense. The IT budget should be about helping you move faster, making you more agile than competitors, and giving you the edge that made your business successful in the first place. If every time you need a new feature, your team tells you it’s too risky, takes six months, or just plain can’t be done, then your technology isn’t just old—it’s holding you back.
Modernization, when done right, frees up budget and brainpower for things that actually push the business forward. Whether it’s integrating a cloud CRM, giving sales teams better tools, or making operations run smoother, every IT move should support a real business goal—scaling up, responding faster, or staying ahead of the market. And when leadership sees modernization actually cutting costs and opening new opportunities, they’ll get behind it.
Bottom line? Tech should be your secret weapon, not your ball and chain. If your IT spending is all about survival instead of growth, I would humbly suggest that you’re doing it wrong (I know, easy for me to say).
The Real Problems with Legacy Systems
Okay, we’ve painted the big picture—modernization isn’t about chasing trends, it’s about keeping your business agile and competitive. But let’s get specific. What are the actual problems you might be dealing with your legacy system?
We will discuss it, making explicitly reference to the classical situations of RPG-based EPR or MPR systems, but the situation is very similar if you are using EGL, some long-forgotten 4GL, or maybe Visual Basic 6.
1. The Code is a Mess
Nobody really knows how it all works anymore. Over the years, these systems have been patched, extended, and customized—often by developers who are long gone. Documentation? If it exists, it’s outdated or incomplete. Yes, there are low-level comments on single functions (not always aligned with the code), but the overall picture is not captured anywhere. That makes every change a high-risk move—because when one part of the system depends on another in undocumented ways, a small tweak can trigger unpredictable failures. So the default answer of the technical team becomes “It cannot be done,” and if you keep pushing, they shoot you a crazy estimate, so that you will just leave them alone.
2. Finding RPG Devs is Like Finding a Unicorn
Where are all the RPG developers? Most of them are retiring or have already left the workforce, and almost nobody is learning RPG today. That leaves you dependent on a shrinking pool of experts, driving up costs and increasing the risk of losing critical business knowledge.
The reality is that the average RPG developer is over 55 years old, and most young developers have never touched RPG. That means every time a key RPG expert leaves, maintaining your system gets even harder. Companies running RPG-based systems consistently report hiring challenges as their #1 modernization blocker—not because they don’t want to update their systems, but because they don’t have the people to do it.
Sure, you could convince people to join your company without knowing RPG and then teach them. But does it seem an efficient and sustainable thing to do for years to come? Are the brilliant young developers out there dreaming of learning and working with RPG?
3. They Don’t Play Well With Others
Trying to connect an RPG-based ERP to modern cloud platforms, mobile apps, or external APIs? It’s a constant battle. These systems weren’t designed for integration, meaning every connection requires custom-built middleware, brittle workarounds, or slow batch processes. It made sense at that time to have “one system that just worked”, but today software is more pervasive, and you want to add more “stuff” and plug or replace components over the years. That was something legacy systems were not designed to support.
Many companies still using RPG struggle with green-screen interfaces and outdated data structures, making automation and real-time integration nearly impossible. And in today’s business world—where APIs and cloud services are the norm—running an isolated system is a major disadvantage.
4. They’re Not Flexible
Want to add a new feature? It’s going to be a struggle. The codebase is a mess: it’s all connected, and no one knows how it works. Even small updates take ages, or get put on hold because they’re too risky. This means the business slows down, all new ideas are just deemed “impossible to implement”, and the competition gets ahead.
A survey of IT leaders found that 70% say their legacy applications prevent them from quickly adapting to market changes. And when making a change takes six months while your competitors can try out things in weeks, learn and refine, you’re no longer playing on a level field.
5. Waiting Just Makes It Harder
If you don’t act now, the problem will only get worse. Every year, RPG knowledge becomes harder to find, system complexity increases, and the cost of migration goes up. This would be a good point to add a sentence to soften the news and paint a more rosy picture, but I cannot come up with anything. Sorry.
Ways to Actually Fix These Systems
There’s no magic wand that instantly modernizes an RPG-based system, but there are strategies that have been applied and worked well. Let’s take a look, and hopefully they will be of inspiration.
Strategy 1 – Automated Code Conversion
For companies looking for a more direct transition away from RPG, automated code conversion tools can provide a head start. These tools translate RPG code into modern languages like Java, C#, or Python while preserving the original business logic. While this doesn’t create fully optimized modern applications, it removes the manual effort required for migration. After the translation, you can refactor the solution over time, if you wish.
The biggest advantage of this approach is speed—instead of rewriting millions of lines of RPG code from scratch, companies can use automated tools to generate an initial version of the new system, which can then be refined over time. This can reduce migration timelines from several years to just 6–18 months, depending on the complexity of the system.
However, automated conversions are not perfect. The resulting code is often functional but not optimized, meaning that developers will still need to refactor, clean up, and validate. The good news is that now that the system is in a more modern language, you can find talent, and you have access to better development tools.
Strategy 2 – Make it more modular through APIs
One of the best ways to make an RPG-based system more useful without rewriting it is to wrap it in APIs.
In practice, we mean taking your existing RPG system and breaking it up into modules that communicate between them through clearly defined (and documented) APIs. This will permit to build new components that replace some of these “RPG silos” or that provide additional features.
This will not completely solve the problem: you will still have a lot of RPG around, but over time you could replace those components, and in the meantime, you can build new applications that integrate with RPG through the APIs.
While APIs can extend the lifespan of a legacy system, they don’t eliminate the underlying maintenance burden—at some point, core modernization will still be necessary.
Strategy 3 – Off-the-Shelf Replacement (e.g., SAP Business One) with Business Logic Extraction
Another option is to throw everything away and adopt an off-the-shelf solution like SAP Business One, then recover the business logic from the existing system and use it to configure the new one. This is a radical approach, and while it may seem like a clean break, it comes with two massive challenges that make it both time-consuming and expensive.
The first challenge is recovering the business logic. Your RPG-based ERP has likely evolved over decades, with business rules deeply embedded in its code, intertwined with system-specific logic, and lacking clear documentation. Unlike modern systems where processes are neatly mapped out in workflows, many RPG systems operate on implicit rules that only exist inside the code or in the heads of long-time employees. Extracting and formalizing this logic is a significant undertaking. This is something we’ve been working on recently, and we may be able to help—but for now, let’s be honest: it’s a challenge.
The second challenge is translating that business logic into the new ERP system. Once you’ve successfully extracted and documented the processes, you then need to work with SAP (or other ERP) consultants to implement them correctly. This means extensive configuration, customization, and testing. And, as anyone who has gone through a major ERP migration can tell you, these projects are long, expensive, and difficult to get right.
Realistically, you should expect at least 12 months, and more likely between 18 and 36 months, to complete this process. The time required to extract the business logic can be significantly reduced with the right techniques, but as far as we know, the implementation and configuration of a new off-the-shelf ERP cannot be compressed much—it’s inherently a slow and methodical process.
This approach makes sense if your current system is truly unsalvageable and you are already committed to transitioning to a modern ERP platform. However, it’s also the most disruptive and expensive route. For many companies, it’s worth exploring whether incremental modernization (via APIs, cloud migration, or modular replacements) can achieve the same goals with less risk and cost.
Strategy 4 – Aggressive Modernization While Keeping the Legacy System
If moving away from RPG entirely isn’t an option, you can still modernize aggressively within the constraints of your legacy system. This means not just keeping the system running but improving how it is structured, maintained, and extended. While this won’t solve all the fundamental problems of legacy technology, it can significantly reduce maintenance headaches and make the system more appealing for new RPG developers to work on.
There are several steps you can take:
- First, if you’re still using fixed-format RPG (or even RPG II or RPG III), you can migrate to RPG IV in free format, making the code more readable and maintainable. This alone can make a huge difference in how easily new developers can understand and modify the system.
- Second, instead of relying on physical and logical files for data storage, transitioning to a modern SQL database brings better query capabilities, reporting, and integration potential.
- You can also eliminate dead code and reduce code duplication, both of which tend to accumulate over decades, making maintenance much harder than it needs to be.
- Another key improvement is introducing unit tests, which are rarely found in legacy RPG systems. Unit testing makes it safer to refactor and improve code over time without introducing unintended bugs. It also helps document expected behavior, which is particularly valuable when dealing with old, undocumented business logic.
This approach has two major advantages. First, it makes the system more maintainable—cleaner code, structured data, and automated tests reduce the risk of breaking things every time you make a change. Second, it helps with hiring and retaining RPG developers. A modernized RPG system—one that’s easier to read, structured properly, and equipped with testing—is simply more pleasant to work with. Given the difficulty of finding RPG developers, anything that makes the system less painful and more attractive to work on will make recruitment and retention easier.
This isn’t a cheap solution, nor does it solve the bigger issues of RPG developer scarcity or IBM i licensing costs. However, it can be done incrementally, meaning you can modernize parts of the system over time with limited risk. While it won’t make RPG a cutting-edge technology, it will at least make your legacy system a modernized, structured, and more manageable version of itself, buying you time and reducing operational pain. Also, if at some point you decide to migrate, these improvements will also make an automated conversion easier to implement.
Common Challenges During Modernization (and How to Mitigate Them)
Modernization projects always hit roadblocks. Here’s how to handle the common ones.
Legacy Code Complexity & Lack of Documentation
As noted, many legacy systems have sparse documentation – or, let’s be honest, just no documentation at all. And code written in the 80s and 90s. It can be hard to understand the exact business rules buried in legacy programs.
Mitigation: Start with a thorough discovery and analysis phase. Use automated code analysis tools to map out program flows, dependencies, and even automatically document the existing codebase. Engaging veteran RPG developers (if available) to knowledge-transfer is vital as well. By creating a detailed picture of what your system does, you reduce the risk of surprises during migration. By mapping out every interaction and dependency to plan legacy modernization precisely you can reduce your risks. In short, invest time up front to understand your legacy system before you change it. If you want help in organizing this discovery and analysis phase, this is something we have experience with.
Migration Risks (Downtime, Data Loss, and Project Failure)
Modernizing a core business system is akin to open-heart surgery – there are risks of downtime or even failure if things go wrong. If you do a full replacement, the business could be disrupted during cutover. Moreover, as cited earlier, large-scale rewrite or replacement projects have high failure rates.
Mitigation: Favor incremental and phased migration over “big bang” go-lives. For example, run the old and new systems in parallel for a period, or replace one module at a time (as in a microservices approach). Have robust backup and rollback plans so if a deployment goes awry, you can revert to the legacy system. Rigorous testing is non-negotiable – not just unit tests, but integration tests and user acceptance tests with real scenarios. One best practice is to create a comprehensive test suite against the legacy system’s known outputs and run it against the new system to catch any deviations. Not trivial to pull out, but it helps to sleep better at night.
Cost Overruns and Scope Creep
Modernization projects get expensive fast, and the quickest way to blow your budget is by trying to do everything at once. If you go into a project thinking, “Let’s rewrite the system, clean up the code, rethink the business logic, modernize the UI, and improve performance”, you’re setting yourself up for a never-ending project.
To avoid this, set a clear goal from the start and stick to it. If the goal is getting off RPG and onto a modern architecture, focus on that. If it’s replacing the UI while keeping the business logic, don’t suddenly decide mid-project to refactor everything. Every additional change—rewriting logic, reorganizing databases, optimizing performance—should be done later, in a separate phase. Trying to cram everything in at once is how projects stall indefinitely.
You also need a real way to measure progress. Don’t trust anyone who promises a fixed timeline—those are usually best-case scenarios that never hold up in reality. Especially if the consultants you are working with are paid by time and material: they get financially compensated by getting late. Who ever thought that was a good idea? In our case, for many of our engagements (including the Migration Blueprint and Migration CodeCraft) we offer a fixed price. This ensures it is in both our interest and the Client’s interest that we complete the project as soon as possible.
Instead, track actual work completed—how many modules have been migrated, how many features are done, and how much legacy code is still in use. The sooner you notice a slowdown, the sooner you can fix the problem before it derails everything.
The best way to keep things on track? Break the project into small, manageable phases. First, migrate the database and core logic. Then, work on the UI. Then, clean up and refactor. Each phase should have its own budget, timeline, and deliverables, and if something starts taking longer than expected, adjust before it snowballs into a disaster.
In short: don’t try to modernize everything at once. Pick a goal, track real progress, and keep the project manageable. That’s the difference between a successful modernization and one that drags on forever. Or at least until you run out of money or patience.
Cultural Resistance and Change Management
People-issues can make or break modernization. Employees who have used the RPG system for decades might resist new tools or fear job loss. IT staff might be defensive about the old system (after all, it’s been their life’s work).
Mitigation: Change management should run in parallel with technical work. Communicate the “why” of the project clearly to all levels – emphasize that modernization is about securing the company’s future (and their jobs), not nullifying past work. Acknowledge the value the legacy system provided, but highlight how business needs have evolved. Involve end-users early by soliciting feedback on pain points and wishlists for the new system – this inclusion helps gain buy-in because people feel heard. Provide training and support as new tools roll out, so users feel confident, not frustrated. It also helps to identify internal champions – respected employees excited about the change who can evangelize to their peers. Lastly, celebrate small wins: when a new feature goes live, or a milestone is hit, publicize it and recognize the teams involved. That builds momentum and turns skeptics into supporters over time.
Conclusion: Practical Recommendations and Next Steps
Embarking on a modernization of an RPG-based ERP/MRP system is undeniably complex, but it is also highly rewarding when aligned with your business’s long-term success. By addressing both the technical and strategic facets, you turn an aging system from a liability into a competitive asset. Let’s recap and outline some actionable next steps:
Step 1 – Assess Your Legacy Landscape
Start with a frank assessment of your current RPG system. Inventory all modules and their business importance, analyze the code quality (possibly using automated scanners), and identify critical pain points and how well the system can support your future business needs. This step often reveals quick wins and informs the priorities of larger initiatives.
Step 2 – Define a Modernization Roadmap
Map out a multi-phase roadmap based on the assessment. Prioritize projects that address the biggest risks and offer the highest business value. Ensure each phase has clear business-aligned goals. This roadmap translates business strategy into tech milestones. Keep it flexible; it can evolve as you learn from each phase and as business conditions change.
Step 3 – Secure Buy-In and Budget
Use the roadmap and business case to get official buy-in and budget. Articulate the cost of doing nothing and the benefits and ROI of modernization at each step. With executive sponsorship and allocated budget, you have the mandate to execute the plan with authority and adequate resources.
Step 4 – Build the Right Team and Partnerships
Put together a modernization team that blends institutional knowledge with fresh skills. This could mean upskilling internal staff, hiring new talent, and engaging external experts. Assign a strong project manager to coordinate between IT and business stakeholders.
Step 5 – Execute in Iterative, Value-Driven Increments
Approach modernization projects in an agile, iterative manner. Deliver smaller increments every few weeks if possible, every few months otherwise, and gather feedback. Each increment should deliver tangible value or learning, which reduces risk and allows the business to start reaping benefits early.
Step 6 – Focus on Change Management Throughout
Parallel to technical work, keep executing your change management plan. Continue updating everyone on progress, training users for upcoming changes, and capturing feedback. Monitor adoption of new tools and be ready to adjust.
Step 7 – Measure, Adapt, and Evolve
Establish metrics to track the success of modernization against your business goals. Report these wins and be candid about any shortfalls. Use a continuous improvement mindset. A tech strategy aligned with business goals is not a one-and-done project; it’s an evolving program. As new technologies emerge, incorporate them into your roadmap where relevant to the business.
By following these steps, a company with a legacy RPG-based system can methodically transition to a modern, agile technology footing. It’s a journey that addresses immediate risks (like legacy maintenance costs and developer shortages) while setting the foundation for long-term growth and innovation.
I am not going to sugarcoat it: the challenges of legacy modernization – from decoding old code to managing change – are significant, but they are far outweighed by the risks of standing still. Clinging to outdated systems eventually holds back business initiatives, whereas application modernization removes obstacles to progress. In plain terms: modernizing your tech is investing in your business’s future.
What you want to do is to build Long-Term Success through Alignment Between your Technology and your Business Needs. Doing business is difficult under the best circumstances, and your technology should be a catalyst, not a constraint. Legacy RPG systems served well in their day, but the future belongs to flexible, integrated, and intelligent systems. By undertaking a thoughtful modernization – and openly addressing challenges like legacy code maintenance, the RPG developer shortage, and migration risks at each step – you position your company to thrive for the next decade or two. The road isn’t easy, but, is the alternative any better?
Resources
You can read this article, to discover more about The Migration Blueprint and this article to discover more about The Migration CodeCraft.
You can discover more about migrations here and get in touch with our team of experts!
