How Do IBM iSeries Consulting Services Preserve Business Logic?

An IBM i estate rarely fails because the platform stops working. The hardware is reliable, the operating system receives updates, and applications written in the 1990s continue to process transactions correctly every night. 

What fails is the ability to change any of it. The person who knew why the credit hold routine has an exception for a particular customer category retires. The analyst who could explain which of three similar programs is the live one moves on. Gradually the organization arrives at a system it depends on completely and cannot safely modify, which is a business continuity problem wearing a technology costume. 

That is why the useful first deliverable from IBM iSeries consulting services is knowledge extraction rather than a modernization roadmap. 

The Skills Position Is Now the Top Concern 

The community has been saying this for years and the data now leads with it. 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 the leading position it had held for nine consecutive years. 

That shift matters because it changes what a shortage means. A cybersecurity concern is addressable with tools and process. A skills concern in a platform with a shrinking practitioner base is addressable only by capturing what the current people know, or by paying substantially more for the diminishing pool who still know it. 

IBM's own material acknowledges the same pressure, describing a skills cliff in which the programmers who built these systems are retiring while RPG is rarely taught in universities. The same source cites research from the IBM Institute for Business Value finding that 83% of executives called modernizing applications and data central to their strategy, while only 27% said they had actually modernized many of the necessary systems. 

The gap between those two figures is where most IBM i estates sit: recognized as important, largely untouched, and dependent on people who are closer to retirement each year. 

The Asset at Risk Is the Logic, Not the Code 

Be precise about the asset, because it determines the work. 

The code is not the asset. Source is on disk, backed up, and readable by anyone who learns the language, which is a smaller obstacle than commonly assumed. 

The asset is the accumulated business logic: thirty years of decisions about how this company prices, credits, allocates, and reconciles, encoded in programs and never written down anywhere else. Some of it implements regulation. Some implements contracts with named customers. Some was a workaround for a system that no longer exists, and nobody can now tell which is which. 

Three specific categories carry the most risk. 

Undocumented exception handling, meaning the conditional branches that exist because something unusual happened once. These are the rules most likely to be lost in any rewrite and most likely to matter when they are. 

Implicit sequencing, where a nightly job depends on another finishing first for reasons nobody recorded. These break in ways that appear random. 

Data semantics, where a field means something other than its name suggests, or means different things depending on a flag elsewhere. Every migration project discovers several of these, usually after the data has moved. 

What IBM iSeries Consulting Services Should Extract First 

Sequence the extraction by how much knowledge is at risk of walking out, rather than by application importance. 

1. Interview the people, first and urgently. Two hours with the analyst who has been there 25 years produces more usable knowledge than two weeks of code reading, and that opportunity has an expiry date.

2. Map the job schedule and its real dependencies, including the ones enforced by timing rather than by declaration. 

3. Extract the decision logic from the programs that implement pricing, credit, eligibility, and allocation, expressed as business rules rather than as code summaries. 

4. Document data semantics per field on the core files, including which values are still in use and which are historical. 

5. Identify dead code and unused programs, since the estate is invariably smaller than it appears and every retirement reduces future scope. 

Record why alongside what. A document stating that a program applies a 2% discount when a flag is set has captured the mechanism. A document stating that the discount implements a 2004 distribution agreement with a customer segment that no longer exists has captured something that lets the business decide to remove it. 

Automated analysis helps and does not substitute. Tooling maps call graphs, finds dead code, and traces field usage far faster than a person, which makes the human interviews more productive because they can focus on intent rather than on structure. 

Running the Interviews Well 

The human phase is the part with a deadline and the part most often done badly, so it deserves specific attention. 

Send the questions in advance. Long-serving people can recall an enormous amount with a prompt and very little cold. A list of the programs and processes to be discussed, sent a week ahead, produces conversations that start at the interesting part. 

Record and transcribe, with permission. The detail people volunteer in passing is frequently the most valuable content in the session and never survives in handwritten notes. 

Ask about failures rather than about design. What went wrong at year-end three times running, what the workaround was, and why the workaround is still there produce more real rules than any question about how the system works. 

Interview in pairs where possible, pairing the long-serving person with whoever will inherit the system. The transfer that happens in that room is worth more than the document produced afterward, and the newer person asks the questions a consultant would not think to ask. 

Finally, treat the sessions as respectful rather than extractive. People who suspect the exercise is preparation for making them redundant will be helpful and incomplete, and the omissions are undetectable. Being straightforward about the purpose costs nothing and materially changes what gets captured. 

Documentation That Survives Contact with a Project 

Most documentation produced in these engagements is never read again, and the reason is format rather than effort. 

Three properties make it durable. It lives where developers work, in the repository alongside the source rather than in a document management system nobody opens. It is organized by business capability rather than by program name, since the next project will start from a business requirement. And it records decisions and their rationale rather than describing code, because code can be read and rationale cannot be recovered. 

Two artifacts repay the effort more than any others. A business rules catalogue, listing each significant rule with its source program, its business owner, and its origin. And a data dictionary for the core files with real semantics rather than field descriptions copied from the definition. 

Keep both current with a light process: any change to a documented rule updates the catalogue as part of the change. Without that, the documents describe the system as it was on the day the engagement ended. 

The Case for Doing This Without a Modernization Decision 

Extraction is frequently deferred until a modernization program is funded, which gets the sequence backwards. 

Every option the organization might later choose depends on this knowledge. A rewrite needs the rules. An API-first modernization needs to know which logic to expose. A package replacement needs the rules to evaluate fit. Staying on the platform and hiring needs the documentation to make new people productive. Even a decision to do nothing benefits, because the risk becomes quantified rather than vague. 

The cost is also modest relative to any of those options, and the timing constraint is external. An organization that extracts knowledge this year has the option to decide later. One that waits until the modernization business case is approved will find that two of the three people who understood the system have gone. 

Budget context supports doing it now rather than later. Gartner forecasts worldwide IT spending reaching $6.37 trillion in 2026, with IT services including application implementation and managed services exceeding $1.87 trillion. Competition for the small population of experienced platform practitioners rises alongside that spending, and the rate for their time follows. 

An IBM i company weighing this should also note the operational return that arrives immediately. Documented rules reduce the time to answer a business question, shorten incident diagnosis, and make it possible to onboard a contractor without a three-month ramp. Those benefits arrive whether or not anything is modernized. 

Choosing a Partner for IBM iSeries Services Work 

The capability required here is unusual: platform fluency plus the patience for archaeology, plus enough business literacy to ask why a rule exists. 

Ask any candidate for IBM iSeries services to describe the last business rule they extracted and what it turned out to mean. Practitioners who have done this work tell the story readily, and it is usually a good one. 

Ask how they handle the case where the code and the documented process disagree. The answer should involve going to the business rather than assuming either source is authoritative, since the code describes what happens and the documentation describes what someone intended. 

Ask what they leave behind and in what format. The engagement's value is entirely in the artifacts, and a partner who produces slides has misunderstood the assignment. 

Then ask about knowledge transfer to your own people. IBM iServices delivered as a black box create a second dependency on top of the first, which is the opposite of the intended outcome. 

IBM iSeries consulting services preserve business logic by extracting rules and their reasons while the people who know them are still available, which is a different and more urgent project than modernization. Trustworthy partners structure IBM i engagements around that extraction first, and teams facing a retirement wave can begin with an IBM i knowledge and rules assessment. Work out how many people in your organization could explain the pricing logic in your core application, and how many of them will still be there in three years.