It is budget season. Across IT departments, planning spreadsheets are open, last year's numbers are being rolled forward, and leaders are deciding which priorities make the cut for 2027.
For IBM i leaders, the conversation tends to follow a familiar pattern. Licenses and support renew. A hardware or OS upgrade gets scheduled. Production support gets staffed. And the work that would actually improve the applications running the business gets whatever room is left over, which is often not much.
This year, the backdrop makes that pattern riskier than usual. The headline numbers suggest money is flowing into IT. The details suggest it is flowing somewhere specific, and probably not toward the applications your business runs on.
The Budget Is Growing. That Does Not Mean Yours Is.
On October 21, Gartner released its latest IT spending forecast, projecting that worldwide IT spending will reach $7.35 trillion in 2027, up 15% from 2026. It is the first time the total will cross $7 trillion.
The growth, though, is concentrated. Gartner attributes most of it to AI infrastructure and AI software, with data center systems spending forecast to grow 55.5% in 2027. IT services, by comparison, are forecast to grow 4.9%.
Price is also doing some of the work. Gartner reports that data center demand has more than doubled memory prices over the past 12 months, with increases cascading through storage, server, networking, and device supply chains. The firm expects this pressure to persist through 2027 before hardware pricing begins to stabilize.
For an IBM i organization, the practical meaning is straightforward. A larger IT budget can coexist with less real room for application work. Part of any increase may be consumed by higher infrastructure costs, and much of the new money across the industry is being directed to AI initiatives. The applications that process orders, manage inventory, and run invoicing are competing for what remains.
That makes deliberate planning more important, not less.
The Three Buckets in Every IBM i Budget
A useful way to structure an IBM i budget is to separate spending into three buckets.
Run is the cost of keeping current applications operating: production support, fixes, licenses, and the time your developers spend keeping things working.
Platform is the infrastructure underneath: hardware, operating system upgrades, high availability, and hosting.
Change is investment in the applications themselves: work that makes them easier to modify, less dependent on a few individuals, and able to support what the business needs next.
The planning trap is that run and platform spending tend to fund themselves. They come with renewal dates, support deadlines, and hardware lifecycles that force a decision. Change spending has no deadline attached, so it is the bucket that gets trimmed when the numbers do not add up. Our earlier post on what technical debt is really costing IBM i organizations (opens in a new tab) covers how that imbalance compounds over time, as run costs quietly crowd out change.
The fix is not necessarily a bigger budget. It is protecting the change bucket on purpose, with a defined amount and a defined outcome, before the run and platform lines absorb it.
Use the Upgrade Window
Many IBM i organizations already have a platform investment on the calendar. In Fortra's 2026 IBM i Marketplace Survey, a record 70% of respondents reported plans to upgrade their hardware, software, or both, following IBM's release of IBM i 7.6 and Power11.
If your organization is part of that group, the upgrade is an opportunity worth using. It puts IBM i on leadership's agenda, brings budget attention to the platform, and creates a natural moment to ask a bigger question: if we are investing in the platform for the next several years, what is our plan for the applications that run on it?
Pairing an infrastructure upgrade with a defined application plan turns a maintenance expense into the first step of a strategy. It also gives leadership a clearer answer about what the platform investment is for.
Given Gartner's outlook on hardware pricing, it is also worth getting infrastructure quotes early in the planning cycle, so price changes do not surprise you after the budget is set.
What a Change Budget Should Actually Buy in 2027
A change budget does not need to fund a multi-year transformation all at once. In fact, it should not. Our analysis of why RPG replacement projects stall (opens in a new tab) shows how large, long, single-line-item bets carry the most risk.
A well-structured 2027 change budget funds a sequence of smaller commitments, each one earning the next. Futurization™ (opens in a new tab), our proven methodology for building new capability on top of proven IBM i applications instead of replacing them, is built for exactly that kind of incremental funding.
Start by knowing what you have. Before any application work, fund an assessment of the portfolio: which programs carry the most business risk, where the logic is undocumented, and where change will deliver value first. A Profound Discovery assessment (opens in a new tab) is designed for this, and its findings shape every later spending decision.
Fund one increment with a named outcome. Choose a single, contained piece of work tied to a business result leadership cares about: faster turnaround on pricing changes, a capability the sales team has been waiting for, or reduced dependence on one developer for a critical application. A defined outcome makes the investment easy to evaluate at year end.
Protect your highest-risk knowledge. If critical programs depend on one or two people, capturing what those programs do is among the highest-value investments available. It reduces risk immediately, whether or not anything else in the plan changes.
Add capacity without adding permanent headcount. If your team is fully consumed by run work, change will not happen regardless of budget. Agentic Futurization, powered by CoderFlow (opens in a new tab), gives existing teams AI agents that handle work like converting RPG to free-format, refactoring data access to SQL, and documenting programs, with every change validated before a developer approves it. Staff augmentation (opens in a new tab) adds experienced IBM i developers when the constraint is people. Either way, the budget line is for capacity directed at change, not more hours absorbed by run.
Phase It to Fit the Fiscal Year
Structuring the change budget in phases aligned to the fiscal year makes it easier to approve and easier to defend.
Q1: Assess and baseline. Complete the portfolio assessment and record where things stand today: how long changes take, how often they need rework, and which programs only one person can change. Without a baseline, it will be hard to show progress later.
Q2: Deliver the first increment. Execute the first piece of work tied to its named business outcome.
Q3: Measure and expand. Compare results against the baseline and the intended outcome. If the first increment delivered, extend the approach to the next priority.
Q4: Report and plan. Bring measured results into the 2028 planning cycle. A change budget with documented returns is far easier to grow than one that asks for faith.
This structure also gives leadership natural checkpoints. If an increment underperforms, the organization learns early and adjusts, rather than discovering a problem after the full budget is spent.
Three Budget Traps to Avoid
Even a well-intended plan can lose its impact in how it gets structured and presented. The following three traps can turn a reasonable change budget into one that is hard to approve, hard to defend, or easy to cut when priorities shift. Each one is avoidable if you spot it early in the planning process.
The single large line item. Requesting one large allocation for a full replacement or rewrite concentrates risk and delays any return until the end. Incremental funding spreads risk and delivers value along the way.
Funding activity instead of outcomes. A budget justified by the number of programs to be converted invites the question "so what?" A budget justified by a business result answers it in advance.
AI spending that never touches the core. With so much industry spending flowing toward AI, it is worth asking where your organization's AI budget is going. If none of it reaches the applications that run the business, the organization may be investing in AI around its most important systems rather than in them.
What Developers Should Ask For
Budget planning is usually a leadership exercise, but developers often know best where money would make the biggest difference. If you are an IBM i developer with a voice in planning, a few requests tend to deliver outsized value.
Ask for dedicated time to document the programs only you understand. It protects the business and reduces how often you get pulled into urgent questions.
Ask for training that prepares the team for AI-assisted development. Profound Logic's AI Foundations training (opens in a new tab) is built specifically for IBM i developers making that shift.
And ask for tooling that reduces repetitive work, so more of your time goes toward building what the business needs rather than keeping legacy applications running.
Bring a Plan to the Next Planning Meeting
The 2027 budget will be set in the next few weeks. Run and platform spending will make it into the plan on their own. Whether change does depends on whether someone brings a concrete proposal: a defined amount, a first increment, and a named business outcome.
If you want help building that proposal, a Profound Discovery assessment (opens in a new tab) can map your applications and identify where your first change dollars will deliver the most value.
Let’s talk through your 2027 plan with our team, reach out to Futurization@ProfoundLogic.com.