Moving IBM i workloads to the cloud can offer advantages in infrastructure management, scalability, and operational flexibility. But before choosing a cloud provider, organizations need clear answers to two important questions:
- How difficult will it be to leave the provider if our needs change?
- Who is responsible when something breaks?
These questions are about more than technology. They determine how much control your organization retains over its IBM i environment, how quickly problems get resolved, and whether you can make future infrastructure decisions without unnecessary risk.
Cloud evaluations often focus on features, performance, and price. However, without a clear understanding of exit options and operational responsibilities, organizations may discover critical gaps only after a contract is signed—or during an outage.
Here’s what IBM i teams should evaluate before committing to a cloud hosting arrangement.
1. How Can You Avoid Vendor Lock-In in IBM i Cloud Hosting?
Vendor lock-in occurs when an organization becomes dependent on a provider’s technology, tools, or processes to the point that moving to another environment becomes difficult, expensive, or disruptive.
For IBM i workloads, vendor lock-in often develops gradually through decisions made during migration. These choices may seem convenient at first but create dependencies that are difficult to unwind later.
Common sources of cloud vendor lock-in include:
- Proprietary management tools: Systems that depend on a provider’s own software or management interfaces.
- Provider-specific automation: Automated processes that must be rebuilt before moving to another environment.
- Integrated monitoring and backup services: Dependencies on tools that may not transfer easily to another provider.
- Incomplete documentation: Configuration details stored in the provider’s systems rather than documented and accessible to your organization.
Each decision may seem reasonable on its own. The problem emerges when multiple dependencies accumulate and leaving the provider requires significant rework.
What Should an IBM i Cloud Contract Include?
The best time to protect your exit options is before signing the contract—not after you’ve decided to leave.
Your agreement should address several important requirements:
- Data and backup portability: Confirm that you can export your data and backups in usable, documented formats.
- System documentation: Require access to complete configuration documentation, not just a dashboard or summary of your environment.
- Transition assistance: Define what support the provider must supply if you move to another platform or hosting company.
- Notice requirements: Establish how much advance notice is required to terminate the agreement.
- Post-termination access: Specify how long your data and backups will remain accessible after the contract ends.
These terms help ensure that your organization retains practical control over its IBM i environment.
A provider’s willingness to document these commitments is also worth evaluating. If important exit terms cannot be clearly defined before the relationship begins, that uncertainty deserves attention.
2. How Do You Know Whether You Can Actually Leave a Cloud Provider?
A contract may promise data portability and transition support, but those promises are more meaningful when you can verify that the exit process is realistic.
Think of it as a test of your cloud exit strategy. Just as organizations test high availability and disaster recovery (HA/DR) procedures rather than relying solely on documentation, they should validate their ability to transition away from a provider.
Before committing to an IBM i cloud hosting arrangement, consider taking these steps:
- Request a sample data export. Determine what information can be exported and whether the resulting files are usable.
- Review the transition plan. Ask for a detailed explanation of the steps required to leave the environment, rather than relying on a general statement in the contract.
- Walk through a hypothetical migration. Have the provider explain the process, dependencies, responsibilities, and potential challenges involved in moving your IBM i workloads.
- Identify undocumented dependencies. Find out which tools, configurations, and processes would need to be recreated elsewhere.
These discussions help expose potential obstacles while your organization still has the opportunity to negotiate.
The goal isn’t necessarily to plan an immediate departure. It’s to ensure that you retain options if your business requirements, costs, or relationship with the provider change.
3. Who Is Responsible When Something Breaks in the Cloud?
Cloud hosting providers and their customers typically share operational responsibilities. However, the exact division depends on the services included in the agreement.
In a typical arrangement, the provider is responsible for maintaining and restoring the underlying infrastructure, while the customer retains responsibility for aspects of its own workload.
| Responsibility | Typical ownership |
| Physical hardware and underlying infrastructure | Cloud provider |
| Hypervisor and core infrastructure services | Cloud provider |
| IBM i workload configuration | Customer, unless explicitly included in managed services |
| Application and workload resilience | Customer, unless explicitly included in managed services |
| Data backups and recovery | Must be clearly defined in the agreement |
| Incident investigation and resolution | Depends on the failure and contracted support responsibilities |
These are general examples, not universal rules. A managed hosting agreement may assign additional responsibilities to the provider, so the actual contract and service description should determine who does what.
One important distinction is that restoring the underlying infrastructure does not necessarily restore an individual customer’s data, configuration, or workload to its expected operating state.
For example, a provider may resolve an infrastructure outage without automatically recovering a customer’s data or correcting an IBM i configuration problem.
That’s why the statement “the provider handles outages” is not enough. Your organization needs to know which types of failures the provider will resolve and which remain your responsibility.
4. Why Does IBM i Require a More Specific Shared Responsibility Model?
For IBM i environments, a generic cloud shared responsibility model may not address every operational requirement.
The division of responsibility should be defined at the IBM i partition level—not just at the data center or infrastructure level.
When IBM i workloads move into hosted or hybrid environments, organizations may encounter challenges such as:
- Monitoring gaps between the IBM i partition and the surrounding cloud infrastructure.
- Multiple tools for managing different parts of the environment.
- Uncertainty about which team owns an incident that crosses infrastructure and IBM i boundaries.
- Confusion about who investigates problems involving network connectivity, virtualization, and IBM i subsystem behavior.
Consider an outage that involves network connectivity, the hypervisor, and an IBM i subsystem at the same time. The provider may view the infrastructure as operational, while the customer continues to experience a workload problem.
If responsibilities have not been clearly defined, the incident can fall into a gap between the provider’s obligations and the customer’s responsibilities.
A well-defined operating model establishes who investigates the problem, who coordinates the response, and who remains accountable until service is restored.
5. Does Your Cloud Provider Have the IBM i Expertise to Resolve Problems?
One of the most important questions to ask during an IBM i cloud hosting evaluation is:
If something goes wrong at 2 a.m., who do you call—and does that person have the expertise to fix it?
Not every cloud operations team has the specialized knowledge needed to diagnose IBM i issues. Some providers offer broad managed services but primarily staff their support teams with general cloud infrastructure specialists.
That distinction matters when an incident involves IBM i-specific behavior rather than an infrastructure failure.
Ask prospective providers how they handle issues such as:
- An IBM i subsystem hang.
- An object-level authority problem.
- A job queue backup.
- An issue that spans IBM i and the surrounding cloud infrastructure.
For each scenario, determine whether the provider’s support team can diagnose and resolve the problem directly or whether it will hand the issue back to your internal team.
Also clarify:
- Which support services are included in the contract?
- Is IBM i-specific expertise available around the clock?
- Who coordinates incidents involving multiple technical teams?
- What response and resolution commitments apply to different incident severities?
These questions help distinguish infrastructure hosting from the level of operational support your organization actually needs.
6. How Should You Define Operational Ownership in an IBM i Cloud Agreement?
Successful cloud operations depend on clearly defined responsibilities, effective communication, and accountability across both organizations.
Even when the provider and customer each have capable technical teams, an incident can be mishandled if neither party owns the problem from beginning to end.
The solution is to define operational responsibilities in specific, measurable terms before the environment goes live.
Establish a Clear Responsibility Matrix
A RACI matrix identifies who is Responsible, Accountable, Consulted, and Informed for particular activities or incidents.
For an IBM i cloud environment, this can help clarify ownership for:
- Infrastructure outages.
- IBM i partition and workload issues.
- Backup and recovery operations.
- Security and access-related incidents.
- Monitoring and incident escalation.
- Disaster recovery and service restoration.
The matrix should reflect your actual hosting arrangement rather than assume that every provider offers the same services.
Define Support and Escalation Commitments
Your agreement should also specify:
- Incident severity levels: How incidents are categorized based on business impact.
- Response time commitments: How quickly support must acknowledge and begin addressing an issue.
- Resolution expectations: What resolution targets or service commitments apply.
- Escalation procedures: How unresolved issues move to the appropriate technical specialists or decision-makers.
- Managed service boundaries: Which responsibilities belong to the provider, which remain with the customer, and which are shared.
Avoid relying on vague promises of support or best-effort language when your business depends on timely incident resolution.
If a proposal cannot clearly answer who handles a specific failure scenario, resolve that ambiguity before go-live.
7. What Should You Evaluate Before Choosing an IBM i Cloud Provider?
Before making a final hosting decision, evaluate both your ability to leave the provider and the operational support you’ll receive while you’re there.
Use this checklist to guide your discussions.
- Can we export our data and backups in usable formats?
- Will we receive complete documentation of our system configuration?
- Are exit procedures and transition assistance defined in the contract?
- Have we reviewed the practical steps required to migrate away?
- Is responsibility for IBM i workloads clearly separated from infrastructure responsibilities?
- Do we know who handles backup, recovery, monitoring, and incident escalation?
- Does the provider have access to IBM i-specific technical expertise when needed?
- Are response times, escalation procedures, and service commitments documented?
- Is there a clear process for resolving incidents that cross organizational boundaries?
Review these requirements periodically, too. Your environment, provider services, and operational needs may change over the life of the agreement.
Recommendation: Maintain Control of Your IBM i Cloud Environment
Choosing an IBM i cloud provider isn’t just about infrastructure, performance, or cost. It’s also about maintaining control over your environment and understanding what happens when circumstances change.
Two questions deserve particular attention during due diligence:
- Can we leave this provider without unnecessary disruption if our needs change?
- Do we know exactly who is responsible for resolving problems when they occur?
Both questions should have documented answers before migration—not after a difficult transition or a serious outage.
A strong cloud hosting relationship includes transparent exit provisions, clearly defined operational responsibilities, realistic support commitments, and a willingness to address difficult questions before they become urgent problems.
Arbor Solutions Can Help
Evaluating an IBM i cloud environment? Arbor Solutions can help you explore your IBM i infrastructure and hosting needs, understand your options, and plan for long-term operational success. Contact Arbor Solutions to discuss your environment and determine the right next steps.
Read The Other Blogs in This Series about IBM i Applications in the Cloud!
- Article 1: What Are the Actual Costs of Running IBM i Applications in the Cloud?
- Article 2: How Is Security and Compliance Handled in an IBM i Cloud Environment?
- Article 3: Moving IBM i Applications to the Cloud – Beneficial or Just Expensive?
- Article 4: IBM i Cloud Performance and Availability: What Does The SLA Guarantee, and Can You Test It Before Committing?
- Article 5: Leaving an IBM i Cloud Environment? Understanding Strategies and Operational Ownership