IBM i Cloud Migration Checklist

An LPAR (Logical Partition) is a virtualized instance of an IBM Power system — created and managed through PowerVM — running its own copy of IBM i with its own allocated processor, memory, and I/O resources. Before any migration conversation can be scoped or priced, every LPAR in the environment needs to be cataloged: its business role (production, test, development, or an HA node), its OS release and Technology Refresh level, its processor entitlement (shared or dedicated cores), its memory allocation, and its storage layout.

Many IBM i environments have accumulated LPARs over a decade or more, and it is common for the inventory step to turn up partitions nobody can fully explain anymore — an old test environment still running, or a partition supporting a business process that quietly changed hands years ago. This inventory is not a formality: it becomes the basis for sizing the target environment’s core licensing, memory, and storage tiers, and for sequencing which workloads move first, second, and last.

BRMS (Backup, Recovery and Media Services) is IBM i’s policy-based tool for managing backup and recovery operations. A cloud or hosted migration is a natural forcing function to review backup policy end to end: retention periods, full-versus-incremental cycles, save windows, and where media is physically or logically stored.

Virtual tape libraries, cloud object storage targets, and save-while-active options typically behave differently once an environment moves to a hosted or cloud model. In practice, this means BRMS policies usually need to be rebuilt against a media policy tuned for the destination platform, not simply copied over from the source environment.

Every system that talks to the IBM i partition needs to be identified: on-premises satellite systems, warehouse or scanning devices, EDI VANs, output queues and printers, VPN or dedicated interconnects to business partners, and any latency-sensitive 5250 or ODBC traffic.

Once a partition moves off-premises, round-trip network latency changes — sometimes significantly. Workloads with tight interactive response-time expectations, such as warehouse scanning or call center screens, need the new network path designed and tested deliberately rather than assumed to behave the way it did on the local network.

Three layers of testing matter before a migration is considered ready: functional testing (do the applications run correctly on the target), performance testing (does response time and batch/job throughput meet expectations), and failover testing (does the HA/DR design actually work as intended).

A non-production trial migration — standing up a mirror or test partition on the target platform — is a worthwhile rehearsal. Skipping performance testing in particular is one of the most common reasons IBM i migrations run into post-cutover surprises, such as batch windows that no longer fit or interactive response times that degrade because of added network latency.

Power Virtual Server (PowerVS) is IBM’s own consumption-based infrastructure-as-a-service offering for running IBM i, AIX, and Linux on Power infrastructure inside IBM Cloud data centers. Managed hosting typically means a provider owns and operates dedicated or multi-tenant Power infrastructure and manages some or all of the OS and application stack under a service agreement. Private cloud means the organization keeps its own Power infrastructure, virtualized through PowerVM, in a colocation facility or its own data center.

The right choice generally comes down to how much operational control and staffing the organization wants to retain, how elastic the compute needs actually are, how much useful life existing hardware still has, and any compliance or data residency requirements that constrain where the workload can run.