Support tiers are written in the vocabulary of infrastructure: severity levels, acknowledgment windows, resolution targets, escalation paths. Applied to IBM i, that vocabulary describes the least uncertain part of the arrangement.
An acknowledgment inside 15 minutes is straightforward to deliver. What decides whether an incident closes in two hours or two days is whether someone who can read 40-year-old RPG, understand an ILE service program’s binding, and reason about a commitment control boundary happens to be available at that moment.
That variable appears in no tier table, and it is the one worth negotiating over when buying IBM i Series support.
The Skill Is Scarcer Than the Contract Suggests
Take the market position seriously before assessing any proposal.
Fortra’s 2026 IBM i Marketplace Survey found IBM i skills top the concerns at 69%, up from 60% the previous year, displacing cybersecurity from a position it had held for nine consecutive years.
IBM’s own material describes the same condition from the supply side, noting that the programmers who built these systems are retiring while RPG is rarely taught in universities. The pipeline is not refilling on its own, and no support contract changes that.
Two implications follow for a buyer.
Providers face the identical constraint. A support firm manufactures RPG expertise no faster than your own recruiters do, so the useful questions concern how much they hold and whether any of it is contractually yours.
Rates reflect scarcity. A proposal materially cheaper than the field in this market is usually offering fewer hours from less experienced people, and that difference is invisible during routine operation and decisive during an unusual incident.
What IBM AS400 Support Actually Requires: Three Different Skills
Providers describe an IBM i team. Underneath that phrase sit three quite different capabilities, and the mix determines what the arrangement can actually handle.
Operators run the platform: job scheduling, subsystem management, backups, PTF application, performance monitoring, and user administration. This population is the largest, the easiest to hire, and sufficient for most tickets.
RPG maintainers read and modify application code. They can trace a defect through a program, adjust a business rule, and fix a batch job that failed on an unusual record. This is the scarce middle layer and the one most tickets escalate into.
ILE and architecture-level practitioners understand service programs, binding directories, activation groups, commitment control, and the interaction between the application and the database. They are needed rarely and they resolve the incidents nobody else can, particularly anything involving data integrity or a program that behaves differently under load.
Ask for the count in each category, and ask how many of each are assigned to your account rather than to the practice. A provider with 40 operators and two RPG maintainers across the whole client base is offering you a queue for the capability you actually need.
What Named-Resource Depth Means in a Contract
Depth is contractual or it is aspirational, and the difference shows up during a holiday period.
Five provisions turn a general assurance into something enforceable.
- Named primary and secondary individuals for your account, both with documented familiarity with your estate, identified by name in the agreement rather than by role.
- A stated minimum number of people who have completed your onboarding and could work on the estate without a handover, refreshed as staff change.
- Coverage for your actual window, including whether the named people are available during your month-end and year-end, which is when unusual work happens.
- A notice period if a named individual rolls off, with an obligation to onboard a replacement at the provider’s cost rather than yours.
- An escalation path to the architecture-level capability, with a defined time to engage rather than a best-efforts commitment.
The third provision catches an issue buyers frequently miss. Support coverage advertised as continuous is often continuous for operators and business-hours-only for application expertise, which means an RPG problem arising at two in the morning waits until someone qualified starts work.
Where an arrangement covers IBM AS400 support across several clients, ask what happens when two clients have a serious incident simultaneously. The answer describes their capacity honestly or reveals that they have not considered it.
Test the IBM iSeries Support Bench Before You Sign
Organization charts are cheap. A short practical exercise during evaluation produces evidence.
Give shortlisted providers a redacted real problem from your own history: a batch job that failed for an obscure reason, a program whose behavior changed after a release, or a performance issue that took your team a week to diagnose. Ask them to walk through how they would approach it, and watch who in their organization they bring to the conversation.
Three things become visible quickly. Whether the person speaking has genuinely done this work, which is apparent within minutes to anyone who has. Whether they ask about your specific configuration before proposing a cause, which distinguishes diagnosis from pattern matching. And whether they are willing to say that they would need to investigate, which is the honest answer to most real problems.
Then ask for a reference conversation with a client whose estate resembles yours, and ask that reference one question: who did the work when something difficult happened, and was it the person named in the contract?
Matching IBM System i Support to What Remains Internally
The right arrangement depends on what remains internally, and being clear about that changes the specification.
Where an internal RPG capability still exists, the provider supplements it and the priority is coverage during absences and access to architecture-level expertise for the rare hard problem. A smaller, more senior arrangement suits this.
Where the internal capability has gone, the provider is the capability, and the specification needs to include change work as well as support. IBM system i support agreements that cover fixes and exclude modifications leave the business unable to change its own rules, which is a governance problem rather than a technical one.
Where the internal capability is one person approaching retirement, the arrangement should be designed around transferring what they know before they leave. That window is the most valuable and the most perishable asset in the whole engagement.
In all three cases, keep enough platform literacy internally to evaluate what you are told. An organization where nobody can read a job log cannot assess provider performance, and that gap widens over a multi-year contract.
Where the Bench Gets Consumed
A bench that looks adequate on paper gets absorbed by work nobody counted, and understanding where the hours go changes how much depth you need to buy.
Routine operational tickets take the largest share and need the least skill, which is why an arrangement heavy on operators looks efficient until something interesting happens. Application defects consume the RPG maintainers, and their volume tracks how much the business is changing rather than how reliable the platform is. Ad hoc business requests, the ones that arrive as questions rather than tickets, consume more senior time than anyone budgets, because answering whether a calculation can be changed requires reading the code first.
Two categories are consistently underestimated. Month-end and year-end processing generates concentrated demand precisely when the calendar makes cover thin. And integration failures, where a file arrives malformed or a downstream system changes its expectations, present as platform incidents and are diagnosed by the application people.
Track the split for a quarter before renewing. Most organizations discover the mix differs from their assumption, and the finding usually argues for buying less operator capacity and more AS400 application support than the incumbent arrangement provides.
One structural fix reduces the load rather than resourcing it. Where the same category of ticket recurs monthly, the fix is a change to the application rather than a faster response, and a support agreement with no change capacity guarantees the ticket returns.
Reading the Commercial Terms Against the Bench
Price and depth are related, and the relationship is worth making explicit in the evaluation.
Compare proposals on cost per named, onboarded individual rather than on monthly fee. Two providers quoting similar monthly figures can be offering quite different depth, and normalizing on that basis usually reorders the shortlist.
Look at how change capacity is priced. A fixed allocation of days per quarter for application work, with a defined carry-over rule, is more useful than an hourly rate that requires an approval each time, because the approval friction means the work never gets requested until it is urgent.
Check the exit terms for knowledge as well as data. i Series maintenance and support arrangements that end without documentation transfer leave the next provider repeating the discovery you already paid for.
Watch the renewal mechanics too. Multi-year agreements in a scarce-skills market frequently include an annual rate adjustment, and the index it references matters. Where the adjustment tracks a general inflation measure, both sides are pricing against something unrelated to what moved, which produces an uncomfortable renegotiation the first time the specialist market reprices. Agreeing the mechanism openly at signature costs an hour and prevents that conversation.
Finally, weigh the wider budget picture. Gartner forecasts worldwide IT spending reaching $6.37 trillion in 2026, with IT services including managed services exceeding $1.87 trillion. Demand for specialist capability keeps rising while supply stays flat, which argues for locking depth into a multi-year agreement now rather than testing the market again in 18 months.
IBM iSeries support is worth buying on the depth of the RPG and ILE bench behind it rather than on the response minutes in front of it, because the response time is easy and the expertise is the constraint. Professional companies staff IBM i engagements with named continuity across all three skill layers, and teams reviewing a renewal can start with an IBM i support coverage review. Ask your current provider how many named people could work on your estate next Monday, and see how long the answer takes.
