When Do IBM I Managed Services Guarantee Continuity?
Signing a managed services agreement can feel like handing over your risk. For infrastructure, that is largely true. Availability, patching, backups, and monitoring become the provider’s responsibility, with a defined service level attached to each one.
Continuity is different. Most agreements say little about it. A provider may keep the system running, but what happens if its team does not understand why your order allocation program behaves a certain way? You have changed who answers the phone, but you have not changed what happens when an unusual problem appears during year-end processing.
Whether IBM i managed services actually provide continuity comes down to what happens during the first ninety days and whether the contract addresses three areas that are often overlooked.
What a Standard Agreement Covers and What It Misses
A typical agreement spells out the operational responsibilities clearly. It may cover system availability, response and resolution times by severity, patching schedules, backup verification, capacity monitoring, and escalation procedures.
Those protections matter. They do not, however, address the knowledge sitting inside the applications. Three gaps are common.
Application knowledge often falls outside the infrastructure scope. The provider is responsible for keeping the system running, while the client remains responsible for understanding what the applications actually do. That is a problem when the people who hold that knowledge leave.
Change capability is another gap. A contract may cover support without covering application modifications. When the business needs a rule changed, the request then goes back to whoever still knows the system internally. Two years later, that person may no longer be there.
There is also the question of knowledge continuity within the provider. Providers have staff turnover, too. Naming a service provider does not protect you if the person who understands your IBM i environment leaves and nobody else has been brought up to speed.
Three Clauses That Turn IBM i Managed Services into Continuity
These points are better addressed when the agreement is being negotiated, not after the first serious incident.
A dated knowledge capture deliverable. During the transition, the provider should document the application landscape, job schedules, dependencies, and business rules within the core programs. The contract should specify what is delivered, in which format, and by when. The documentation should then be stored in your own repository.
Named continuity on the provider side. At least two people should remain familiar with your environment. The agreement should also specify what happens when one of them leaves the account, including a notice period and the provider's responsibility for bringing the replacement up to speed.
Exit provisions that cover knowledge as well as data. The agreement should spell out which documentation is transferred, the format in which it is provided, the handover period, and whether the outgoing provider will spend time with your incoming team or replacement provider.
The first clause has the biggest effect because it forces knowledge capture to happen while the provider is learning about the environment. It is also the clause providers may resist because documentation takes time and reduces the client's dependence on individual experts. A provider prepared to make that commitment in writing is treating continuity as part of the service rather than relying on client lock-in.
Two additional practices are useful. Review the documentation every quarter so it stays aligned with the system as it changes. Also, capture what the team learns during incidents. Problems often reveal system behavior that never made it into the original documentation.
Transition Is Where Continuity Is Won or Lost
The first ninety days have a major influence on whether the arrangement works. Cutting the transition short to reduce the initial cost can create problems later.
A proper transition should overlap with the people who currently understand the environment. If an internal expert is retiring, the provider should spend several weeks working alongside that person rather than relying on a handover document. If that knowledge has already left the organization, the provider has a different job. It needs to reconstruct how the environment works, and that work should be treated and priced accordingly.
Four activities should be part of the transition plan.
Shadowing through a full business cycle. This should include at least one month-end because unusual processing often exposes dependencies that routine operations do not.
Documentation during the transition. The documentation should be created as the team learns about the environment, not written weeks later from memory. The outgoing expert should review it while they are still available to correct mistakes.
A disaster recovery rehearsal. The incoming team should actually run the procedure rather than simply receive an explanation of how it works.
A list of remaining unknowns. No transition will uncover everything. A clear list of unresolved questions is more useful than documentation that suggests that every dependency has been identified.
That last point matters. Gaps are normal during a transition. A provider that identifies them is giving you a more realistic picture of the environment. A report claiming complete coverage after eight weeks deserves closer examination.
What an IBM i Consultant Adds Beyond Support
There is a useful distinction between operating an IBM i environment and understanding the business logic inside it. That is why some organizations use both managed support and an IBM i consultant.
An IBM i consultant can handle work that a standard support contract may not include. This can involve extracting business rules, assessing modernization options, resolving application defects that require an understanding of business intent, and determining whether a requested change is a configuration adjustment or something that calls for a redesign.
It makes sense to define this work separately in the commercial arrangement. When consulting and analysis are buried inside a support contract, urgent operational issues usually take priority. Documentation and analysis can always be postponed.
A separate allocation of consulting days each quarter, supported by an agreed backlog, gives this work a defined place in the engagement.
IBM's own material points to the growing use of tooling and AI assistance to help teams short on staff or expertise continue modernizing applications. Research from the IBM Institute for Business Value also found that 83% of executives considered application and data modernization central to strategy, while only 27% said they were modernizing many of the systems that needed it.
Tools can help teams understand what existing code does. They do not necessarily explain why a particular business rule exists. That context still has to come from people who understand the system and the business behind it.
Pricing Continuity Honestly
Continuity has a cost, and that cost is easy to see during contract negotiations. This is often where transition work gets reduced.
A transition that includes shadowing through a full business cycle, documentation as the work progresses, and a disaster recovery rehearsal will cost more than a two-week handover. The problem is that the saving appears immediately, while the cost of skipping the work may not appear until an unusual incident occurs much later.
The comparison should therefore be made against the real alternative. Without a documented transition, unusual events can turn into investigations because nobody knows how the system is supposed to behave. Viewed in that context, the additional transition cost is easier to assess.
Two contract structures can help.
First, price the transition separately from the ongoing service. This allows the transition to be scoped properly instead of being squeezed into a monthly fee.
Second, link part of the transition payment to acceptance of the documentation by your team. That gives the provider an incentive to produce documentation that people can actually use, rather than simply producing a large volume of documents.
The monthly rate also deserves scrutiny. A provider offering a substantially lower price may be allocating fewer hours or less experienced resources. On a skills-constrained platform, that difference may not be obvious during routine support. It can become much more apparent when the team has to diagnose an unusual problem.
Testing Whether the Continuity Is Real
Promises about continuity are easy to make. A few practical tests can show whether the provider has actually built the capability.
Start with a scenario exercise before signing or during the first quarter. Give the provider a realistic failure scenario, such as a critical batch failing during year-end close. Ask who gets called, what the team checks first, what information it needs from your organization, and how the response would progress. Detailed answers are more useful than general assurances because they show whether the team has a defined process.
You can also ask for redacted documentation from another client. A provider that regularly produces useful documentation should be able to demonstrate what that documentation looks like without revealing confidential information.
Then test the team's understanding of the applications. Select a core program and ask the provider to explain what it does and why a particular branch exists. This tests whether the team has learned the environment or is simply monitoring it.
For an AS400 managed services arrangement involving an older estate, add another test. Ask what the provider would do if the hardware failed and a replacement could not be obtained immediately. Availability of older Power hardware can create additional constraints, so the response should include a defined plan rather than an assumption that replacement equipment will always be available.
Which IBM i Services to Keep Internal
Moving everything to a provider is not necessarily the objective. The more useful question is which responsibilities should remain inside the organization.
Keep the business relationship internal. Employees should continue to decide priorities, resolve conflicts between departments, and approve changes. These decisions are tied to the business itself and should not disappear along with the operational work.
Gartner's spending forecast provides some wider market context, with worldwide IT spending projected to reach $6.37 trillion in 2026, while IT services, including managed services, are expected to exceed $1.87 trillion. At the same time, organizations still need people who understand the IBM i platform. That makes continuity terms worth addressing when the service is negotiated rather than waiting until renewal.
It is also useful to keep at least one person internally who understands the platform. They do not need to perform the day-to-day work. They need enough knowledge to read a job log, understand the provider's explanation, and question it when necessary. Without that capability, the organization becomes entirely dependent on what the provider tells it.
The operational workload can then move to the provider. This includes monitoring, patching, backup verification, after-hours coverage, and specialized skills that may not make sense to maintain for a single environment.
That division can reduce the operational burden without giving up all internal knowledge. IBM AS400 services structured this way are also easier to transition when a provider changes, because the client still knows what it needs, can assess the work being done, and can participate in the handover.
IBM i managed services provide continuity only when the agreement makes knowledge capture, provider-side coverage, and exit documentation explicit. Experienced providers structure IBM i engagements around this transition work, and teams reviewing a renewal can start with an IBM i continuity assessment.
The first step is simple. Read your current agreement and look for the clause that explains what the provider must document. If there is no such clause, you have identified a continuity gap.
0 comments
Log in to leave a comment.
Be the first to comment.