I like IBM i.
I should probably say that up front, because this is not one of those articles where someone discovers an old system, squints at a green screen for four minutes, and declares that everything needs to be replaced by something “cloud-native” before lunch. I grew up around AS400 systems, RPG, CL, printer files, job queues, menus, reports, and business logic that kept companies running while newer software was still trying to decide which JavaScript framework was morally superior this week.
So no, this is not an anti-IBM rant.
It is almost the opposite.
IBM i is too good a platform to buy lazily. It is too powerful to size by fear. It is too important to treat like a mysterious black box where every invoice gets approved because nobody wants to ask what the system actually does.
That is where companies get into trouble.
The AS400 is not expensive in the abstract. IBM i is not expensive in the abstract. Power hardware, licensing, tools, support, high availability, disaster recovery, modernization platforms, reporting products, and consulting are not automatically wasteful. They can be absolutely worth the money when they match the workload, risk, and business value.
The waste starts when companies stop asking what they are actually using.
I have seen businesses paying for far more platform than the job requires. Not because anyone was trying to be foolish, usually. More often because the AS400 runs something important, nobody wants to be the person who breaks it, and “buy more” feels safer than “understand better.” That is understandable. It is also how companies end up using a tiny slice of what they are paying for while treating the rest like sacred insurance.
Buying blindly gets expensive.
IBM i earns its keep when the workload fits
There are places where IBM i is still a very good answer.
If the system is running business-critical transactions, acting as the system of record, handling inventory, billing, accounting, manufacturing, distribution, logistics, reports, batch jobs, or long-lived RPG business logic that has survived decades of real-world exceptions, I am not casually interested in ripping it out because someone is offended by a green screen.
Old does not mean bad. Ugly does not mean wrong. Boring does not mean obsolete.
A lot of IBM i systems are still around because they do important work. They are stable. They are integrated. They have strong operational history. They run the processes that make sure orders are shipped, invoices are generated, inventory is tracked, reports appear, and customers are not accidentally turned into philosophical questions.
IBM’s own material describes IBM i as an integrated operating environment with the database, middleware, security, runtime, and related stack pieces brought together under one platform. That is part of why IBM i can be so compelling for the right kind of business workload. The platform was built for companies that care about reliability, consistency, operational control, and long-lived business logic.
That matters.
If the IBM i is running the part of the business where being wrong is expensive, the platform may be worth every dollar. The right question is not whether IBM i is “modern enough” to impress someone at a conference. The right question is whether it is doing work the business cannot afford to mess up.
Sometimes it is.
Sometimes it very much is.
Capability is not the same thing as fit
Here is where people get themselves into trouble.
IBM i can do a lot. Power systems can do a lot. Vendors can sell a lot. Add-ons can add a lot. Consulting proposals can become thick enough to stun livestock if dropped from a decent height.
Capability is good. Buying capability you do not need is less good.
A business may need reliability, but not the most elaborate disaster recovery architecture anyone can imagine. It may need better reporting, but not a giant reporting platform nobody will use properly. It may need integration around the AS400, but not a full rip-and-replace modernization project. It may need support and documentation, but not a gold-plated enterprise plan purchased because everyone got nervous in a meeting.
This is where right-sizing matters.
What is the actual workload? How many users are really using the system? What are the peak periods? Which jobs matter? Which reports are critical? What is the real recovery-time requirement? What is the real recovery-point requirement? What happens if the system is unavailable for an hour, a day, or a week? Which tools are actually being used? Which licenses are sitting there like expensive furniture in a room nobody enters?
The platform may be powerful, but the business still deserves a configuration that fits.
Buying the aircraft carrier version to move a canoe is not “being safe.” It is a budgeting decision wearing a helmet.
Fear is an expensive architect
A lot of overbuying happens because the system is important and nobody wants to touch it.
That fear is not irrational. If an AS400 system has been running the company for decades, there is probably real risk around it. There may be old RPG programs nobody wants to modify. There may be reports people rely on but do not understand. There may be nightly jobs, printer output, EDI processes, old integrations, customer-specific logic, or one person who “just knows” how everything works.
That deserves caution.
It does not require panic purchasing.
Fear makes expensive architecture look responsible. It makes every vendor recommendation sound like insurance. It makes every unused module feel like something you might need “just in case.” It turns “we should review this” into “please approve the renewal before someone asks a question and accidentally becomes responsible.”
That is how companies end up with spend that no longer matches use.
The business keeps paying because the system matters. The system matters because it runs the business. Nobody wants to question the spend because questioning the spend feels like questioning the system. Eventually the invoice becomes part of the ritual.
A good IBM i review separates respect from superstition.
Respect says, “This system is important. We should understand it carefully.”
Superstition says, “Do not ask questions. Just keep paying.”
Those are not the same thing, even if they sometimes appear in the same boardroom wearing similar shoes.
The right spend protects the business
The goal is not to cheap out on the system that runs the company.
That would be stupid.
If IBM i is the heart of the operation, it should be supported properly. Backups should be understood. Access should be controlled. Maintenance should not depend on folklore. Support arrangements should make sense. Hardware, hosting, licensing, upgrades, monitoring, security, recovery planning, and technical knowledge should not be held together by a retired developer’s memory and a prayer.
There are places where spending more is the responsible answer.
If downtime would stop shipping, payroll, invoicing, production, dispatch, or customer service, then the business should not be playing discount roulette. If the release is near end-of-service and support exposure is growing, that matters. If the machine is overloaded, the workload is changing, or the company is adding users and integrations, capacity planning matters. If the only person who understands the RPG code is retiring, documentation and support matter.
IBM’s own release lifecycle and support documentation exist for a reason. These systems need planning. The boring operational stuff matters because it is the stuff that keeps a business from discovering at the worst possible moment that “it has always worked” was not a strategy.
The point is not to spend less at all costs.
The point is to spend where the risk and value actually are.
That is the part too many companies skip.
The waste is often around the edges
In many IBM i environments, the core system still works. The waste is around the edges.
The business is paying for tools nobody uses. Reports get exported and reworked in Excel because the reporting layer never really matched how management thinks. Staff manually re-enter data into newer systems because nobody integrated the workflow properly. Expensive modernization products get discussed while the real pain is one miserable handoff between sales and operations. High availability gets priced without anyone agreeing on what downtime actually costs. A vendor sells a large solution because the business asked a large, vague question.
This is why the first step should usually be understanding.
Where is the actual pain? Is it the AS400 itself, or the systems around it? Is the problem performance, reporting, access, integration, knowledge, licensing, support, hardware age, or workflow? Is the business paying for unused capacity, or is it failing to invest in the one area that would actually reduce risk? Is the modernization conversation about real operational need, or is everyone just uncomfortable with the age of the interface?
Those questions are not glamorous, but they save money.
Sometimes the expensive platform is justified and the cheap workaround is the real danger. Sometimes the expensive add-on is overkill and a focused integration would solve the problem. Sometimes the business should keep the IBM i stable and modernize only the parts around it. Sometimes the old workflow should be documented before anyone buys anything.
The boring answer is often the profitable one.
I realize “boring answer” does not make for an exciting sales deck. That is probably why so many sales decks are full of nonsense.
Modernization does not always mean replacement
There is a special kind of vendor confidence that appears right before a company gets talked into replacing something it does not understand.
The old system looks old. The proposal looks modern. The screenshots have rounded corners. Everyone gets a little excited. Somewhere in the background, an old RPG program containing twenty years of customer-specific business logic begins softly screaming.
Modernization can be valuable. Sometimes replacement is the right answer. Some legacy systems are brittle. Some workflows have outgrown the platform. Some business rules need to be rebuilt. Some technical risks are real. Some old systems are being kept alive only because everyone is afraid to look directly at them.
But modernization should start with the business process, not the sales brochure.
Sometimes the better move is enterprise integration. Sometimes the IBM i should stay the system of record, while newer systems get better ways to read from it, write to it, report on it, or trigger workflows around it. Sometimes the business needs a modern web form, customer portal, reporting layer, API, internal tool, or workflow application that talks to the old system without pretending the old system has to disappear overnight.
Sometimes modernization means building a bridge.
That is less dramatic than “we are replacing everything,” but it is usually easier to survive.
In our earlier article, Green Screens, Dot Matrix Printers, and the Business Logic Nobody Wants to Admit Is Brilliant, the main point was that old systems often contain real business knowledge. This article is the financial cousin of that idea. If the system still contains business value, the goal is to preserve what earns its keep and stop paying for what does not.
That requires judgment.
Not vibes.
Not panic.
Not an invoice approved because everyone is scared of the green screen.
Right-sizing starts with actual usage
An IBM i right-sizing review should begin with actual use, not mythology.
What applications are running? Which users are active? What are the peak times? What jobs are scheduled? Which reports matter? Which interfaces exist? Which tools are licensed? Which tools are used? Which workflows depend on the system? Which parts of the business would stop if the machine went down? Which parts would be inconvenienced but survive? Which support agreements are critical? Which ones are mostly habit?
IBM provides performance and capacity resources, including workload-estimation and performance-reference material. Those kinds of tools exist because sizing should be based on workload, not hand-waving. A serious review should connect technical metrics to business reality.
That last part matters.
CPU usage by itself does not tell you whether the system is important. A lightly used system might still be mission-critical if the work it does is essential. A system may be underutilized technically but central operationally. Another system may be overbuilt because someone once imagined growth that never happened. A third may be overloaded in one nightly batch window while sitting bored for the rest of the day like a very expensive cat.
Right-sizing is not just shrinking.
It is matching the platform, support, and modernization plan to the business.
Sometimes that means reducing waste. Sometimes it means spending more in the right place. Sometimes it means moving budget from unused tooling into documentation, support, integration, or reporting that staff actually need. Sometimes it means admitting the current setup is underbuilt and the company is gambling with the wrong thing.
Right-sizing is not the same as cheapening.
Cheapening asks, “How do we spend less?”
Right-sizing asks, “What should this system actually cost for the value and risk it carries?”
That is a much better question.
The vendor quote needs a translator
A lot of business owners and executives are in a difficult position with IBM i. They know the system matters, but they do not always know how to interpret the technical recommendations. They may receive a quote full of hardware, software tiers, subscriptions, licensing, maintenance, support, HA/DR options, tools, monitoring, consulting, modernization products, and acronyms that reproduce when left unattended.
Some of the quote may be necessary. Some may be sensible. Some may be optional. Some may be more about what is easy to sell than what is best for the business.
The problem is that without someone who understands both the IBM i world and the business process, everything can sound equally important.
That is where companies overbuy.
They approve the whole thing because they do not want to underprotect the business. Again, understandable. But expensive. The better approach is to translate the quote back into business terms.
What risk does this line item reduce? What happens if we do not buy it? Who uses this tool? What process improves? What downtime scenario does this protect against? What is the recovery requirement? What is the actual workload? What is the growth plan? What is the support exposure? What business outcome does this modernization product create? Is this solving a real problem, or are we buying comfort because nobody has mapped the system?
A good technical advisor should be able to say, “Yes, this is important,” and also, “No, this probably does not match what you are doing.”
Both answers save money.
One saves you from underinvesting.
The other saves you from buying a battleship because the pond looked mysterious.
The cheapest option can still be reckless
I do not want this article to sound like “spend less on IBM i.”
That would be too simple and, in some cases, dangerously wrong.
The cheapest option can be reckless. If your system runs orders, inventory, invoicing, manufacturing, or logistics, and the business cannot function without it, under-supporting it is not frugal. It is a slow-motion incident report.
I have seen businesses treat critical systems like old furniture. They know it is there. They depend on it. They do not maintain it properly. They do not document it. They do not review access. They do not know who can support it. They do not know what the recovery process looks like. They have never fully tested the scary scenario because testing it would force everyone to admit the plan is mostly vibes and one guy named Gary.
That is not saving money.
That is hiding risk in the walls.
The right answer may be to spend more on documentation, backups, monitoring, support, upgrade planning, security review, or modern development practices. It may be to get the system onto a more supportable release. It may be to bring in people who understand RPG, CL, Db2 for i, integrations, APIs, and the operational weirdness around the platform.
This is why Panda Rose connects IBM i work with managed IT support, business analysis, technical consulting, and custom software development. The system is not just hardware or licensing. It is part of the business.
A company can waste money by buying too much.
It can also waste money by refusing to invest in the part that actually protects the business.
Right-sizing means knowing which is which.
Sometimes the savings are not in IBM at all
One of the funny things about reviewing IBM i spend is that the best savings are not always inside the IBM i invoice.
Sometimes the platform is fine. The waste is in the manual work around it.
Staff are exporting reports every week and rebuilding them in Excel. Sales enters something in one system, operations re-enters it somewhere else, and accounting fixes the leftovers. The website collects customer information, but someone manually types it into the old system. Managers ask for reports the IBM i can produce, but nobody has updated the process, so people keep paying with labour instead of fixing the workflow.
In those cases, cutting IBM i spend may not be the best move. The business may save more by integrating the system properly, building a better report, automating a handoff, or creating a small internal tool that reduces manual work.
This is where enterprise integration can beat replacement, and where business analysis can save more than a discount.
The system may not be too expensive.
The process around it may be.
That distinction matters.
If the business is paying people to manually bridge systems all day, the invoice is just hiding in payroll. If staff are correcting bad reports by hand, the cost is hiding in time, errors, and frustration. If the website, CRM, accounting system, and IBM i environment all hold different pieces of the truth, the business is paying for confusion whether or not anyone labels it “software cost.”
The AS400 may be doing its job.
Everyone around it may be compensating for the fact that no one built a sane bridge.
What Panda Rose looks for
When Panda Rose looks at an IBM i or AS400 environment, we are not just asking what model the server is or which release is installed. Those things matter, but they are not the whole story.
We want to know what the system actually does.
Which parts of the business depend on it? Which applications matter? Which jobs run? Which users rely on it? Which reports are critical? Which integrations are real and which ones are just manual work with a nicer name? Which tools are licensed? Which tools are used? Which risks are operationally serious? Which fears are mostly inherited from people who left five years ago?
We also want to know what the business wants next.
Does it need better reporting? Better integration? Better documentation? A modern interface for one workflow? A safer support model? Cleaner backups? Better access control? A plan for RPG maintenance? A move to a supported release? A way for a website or portal to connect to data that still lives on IBM i? A reason to stop exporting the same file every Thursday like it is a sacred ritual?
This is the work.
Not worshipping IBM i.
Not blaming IBM i.
Understanding it.
Then making the business decision with eyes open.
Respect the platform. Question the spend.
IBM i deserves respect when it is doing valuable work.
That does not mean every expense around it deserves automatic approval.
The mature position is to respect the platform and question the spend. Keep what earns its keep. Support what protects the business. Modernize where modernization creates real value. Integrate where integration solves the pain. Document what too few people understand. Right-size the parts that no longer match the workload.
If your business depends on IBM i or AS400 and you are not sure whether your current spend matches what the system actually does, talk to Panda Rose. We can help review the workload, support needs, integrations, risks, tools, reports, and business processes around the system.
The goal is not to cheap out on the system that runs the company.
The goal is to stop paying aircraft-carrier money for a canoe route, while still knowing when the aircraft carrier is exactly what is keeping the business alive.
That is the difference.
