We’ve been brought in to rescue modernization projects that were six months in and already over budget. Almost every time, the root cause was the same: nobody asked the right questions before starting.
Here are the five questions we ask before any engagement — and what the answers reveal.
1. What business outcome are you actually trying to achieve?
Not “we want to modernize our RPG programs.” That’s a method, not an outcome.
The real question: what will be different in your business when this is done? Will orders process faster? Will you be able to enter new markets? Will a key person stop being a single point of failure?
If you can’t answer this clearly, the project doesn’t have a defined finish line. It will run until the budget runs out.
2. What happens if you do nothing?
Some systems are genuinely at risk. The hardware is aging. The one person who understands the code is close to retirement. A regulatory change is coming that the current system can’t handle.
Other systems have been “urgent” for ten years and are still running fine.
Knowing which situation you’re in changes the calculus entirely. Urgency affects sequencing, budget, and risk tolerance.
3. Which parts are causing actual pain right now?
“The whole system is outdated” is not an actionable answer. Push past it.
Where do users complain? Where do workarounds exist? Which processes take the most manual intervention? Which integrations are held together with spreadsheets and scheduled emails?
These are your candidates for modernization. Everything else is optional.
4. What can’t you afford to break?
IBM i systems often run processes that nobody thinks about anymore because they just work. Payroll. Inventory. Order fulfillment. Billing.
Before anything changes, you need a clear inventory of the critical paths — and a test plan for each one. We’ve seen modernization projects pass all their integration tests and still break a billing process that hadn’t been documented anywhere.
This question also reveals how much parallel running time you need. Some systems can’t have downtime. Others can be cut over on a weekend.
5. Who owns this after we’re done?
A modernized system still needs to be maintained, extended, and understood by someone.
If the answer is “we’ll hire people who know modern technology,” that’s a valid plan — but it means the modernized system needs to be documented and structured so that a developer who’s never seen IBM i can work with it.
If the answer is “our existing team will own it,” you need to think about knowledge transfer during the project, not after.
What These Questions Actually Tell You
Run through these five questions honestly, and you’ll know three things:
- Whether this modernization project is justified at all right now
- What to modernize (and what to leave alone)
- How to sequence the work so you’re not gambling the business on a big-bang rewrite
That’s the foundation of every engagement we take on. We’d rather have this conversation before a project starts than be the people who have to deliver bad news six months in.
Talk to us — we’ll work through these questions with you before anyone signs anything.