IBM® i Migrate While Active and Virtual Serial Numbers on Power Virtual Server

Key benefits of Migrate While Active

Production downtime reduced from days to minutes

MWA keeps the source system running throughout the bulk of the migration. Only a brief, planned outage is required during the final cutover to apply the last set of changes and bring the target system online as the new production environment.

Automated data synchronization

After the initial copy phase, MWA continuously tracks and replicates changes from the source to the target system. This eliminates the need for manual delta synchronization and reduces the risk of data inconsistency.

Pre-migration testing with test mode

MWA provides a test mode that allows administrators to bring the copy node up to a usable state and conduct testing or usage scenarios before committing to the final cutover. This significantly reduces cutover-day risk.

IBM i standardized tooling

MWA provides a guided migration experience through the Db2 Mirror graphical user interface (GUI), automating many of the manual steps traditionally required for system migration. Configuration, orchestration, and monitoring are all performed through this unified interface.

Broad object coverage

MWA is designed to migrate all save-eligible objects within SYSBAS, including objects in libraries and the Integrated File System (IFS), far exceeding the scope of Db2 Mirror's replication-eligible subset. This enables complete partition migration rather than selective data replication.

Relationship with IBM® Db2 Mirror for i

MWA directly inherits the core replication engine originally designed for Db2 Mirror for i. While Db2 Mirror maintains synchronous, sub-millisecond coherence between two active production systems using RDMA (RoCE) connections, MWA applies these same mechanisms for asynchronous, migration-oriented replication over standard TCP/IP connections. This shift from synchronous to asynchronous behavior is one of the fundamental differences between the two technologies.

Db2 Mirror contributes essential technology components to MWA, including change tracking services to identify and record modifications on the source node during migration, integration with the Db2 Mirror GUI as the primary migration management interface, and operational visibility through GUI dashboards, WRKMIGSTS panels, and SQL services such as MIGRATION_MANAGER_INFO, LIBRARY_MIGRATION_LIST, and ESTIMATE_FINAL_SYNCHRONIZATION_TIME.

Partition mirroring

Partition mirroring uses host-based storage replication technology to copy SYSBAS from the source node to the copy node. This method has several key advantages:

• No initial outage on the source node is needed because the creation of install media or user data save media is not necessary.
• The host-based storage replication occurs below the technology-independent machine interface (TIMI), so there are no locking considerations or conflicts with ongoing production workloads.
• Because the storage replication processing occurs within the IBM® i operating system, partition mirroring can be used with any storage technology.
• Test mode is available, which allows you to freely and fully evaluate the copy node before finalizing the migration.
• The status and progress of partition mirroring is easy to observe, monitor, and estimate from within the Db2 Mirror GUI.

Partition mirroring migration timeline:

1. Decide whether the existing IBM® i (source node) will be used as the Db2 Mirror GUI node.
2. Install the required products and the latest level of PTF groups on the source node and GUI node.
3. Install IBM® i License Internal Code (LIC) on the IBM® i that will be the target of the migration (copy node).
4. Establish and start partition mirroring. At this point, storage is being asynchronously replicated from the source node to the copy node.
5. After the full synchronization of storage completes, partition mirroring continues to migrate storage as changes are made on the source node.
6. Optionally, transition to test mode to evaluate and test the copy node before completing the migration.
7. After exiting test mode, resuming partition mirroring data replication will bring the copy node back into sync with the storage on the source node. The tracked changes on the copy node are undone and then the tracked changes on the source node are migrated.
8. When ready to complete the migration to the copy node, a final cutover is performed to complete the migration.

Limitations of partition mirroring:

The following environments are not supported by partition mirroring:

• If the source node contains an encrypted user auxiliary storage pool (ASP), it is not eligible for partition mirroring.
• If the source node contains independent ASPs (IASPs), the IASPs will not be replicated using partition mirroring.

Assisted save and restore

Assisted save and restore approaches the migration differently than partition mirroring. An initial outage on the source node facilitates the creation of install media and user data save media, which are used to provision the copy node. Afterwards, IBM® Db2 Mirror for i and Migrate While Active technologies are used to continuously synchronize changes made to objects after the creation of the media. This is ultimately followed by a final migration and cutover to complete the migration to the copy node.

This method is suitable for environments where partition mirroring may not be available, or when the administrator prefers a save-and-restore approach with the added benefit of automated change tracking.

Manual migration

Manual migration provides users with the following alternative methods for creating a copy of the source node to establish the copy node:

• Storage replication (FlashCopy or remote copy)
• Save and restore
• Storage replication and save/restore

Afterwards, IBM® Db2 Mirror for i and Migrate While Active technologies are used to continuously synchronize changes in SYSBAS from the source node to the copy node. This is ultimately followed by a final migration and cutover to complete the migration to the copy node.

The manual storage replication and save/restore migration method reduces source node downtime compared to the assisted save and restore method. Additionally, the manual save and restore migration method provides users with more options for taking a full system save, including but not limited to GO SAVE option 21 or the QSRMIGRATE program.

Choosing a migration method

The choice of migration method depends on the specific requirements of the environment. Review the following considerations:

Why Power Virtual Server for IBM® i?

Power Virtual Server is an IBM® Power-based cloud server offering that enables rapid deployment of virtual servers with flexible, secure, and scalable computing capacity for enterprise Power workloads. PowerVS is available across multiple IBM Cloud multi-zone regions and data centers globally.

PowerVS supports IBM® i version 7.2 and later releases, including IBM® i 7.6. For MWA migrations, the source system must be running IBM® i 7.4 or later with the appropriate Db2 Mirror PTF group levels.

Review the following benefits of using Power Virtual Server for IBM® i workloads:

Scalable cloud infrastructure

Provision Power Virtual Server instances in minutes and scale resources up or down based on workload demands. The pay-as-you-go model reduces capital expenditures and optimizes operational costs.

Same architecture, no re-platforming

Power Virtual Server has the same architecture as IBM® Power on-premises. IBM® i applications run without modification, ensuring a smooth migration with no application refactoring required.

Enterprise-grade security

IBM Cloud provides end-to-end encryption, key management with Key Protect (Key Protect), and compliance programs covering a wide range of internationally recognized standards.

Integration with IBM Cloud services

Power Virtual Server connects to over 190 IBM Cloud services, enabling modernization of IBM® i applications with advanced cloud services including AI, analytics, and DevOps tools.

How MWA works with Power Virtual Server

When migrating to Power Virtual Server, MWA follows the same fundamental process as an on-premises migration. The key steps are:

1. Prepare the source system. Install the required software products (5770DBM *BASE and Option 2), the latest Db2 Mirror PTF groups, and required open-source packages (cloud-init, python39, python39-ibm_db) on the source node. The source system must be running IBM® i 7.4 or 7.5.
2. Provision the target on Power Virtual Server. Create a new Virtual Server Instance (VSI) in Power Virtual Server to serve as the copy node. Ensure that the target has matching levels of Licensed Internal Code (LIC) and is configured with appropriate storage and network connectivity.
3. Establish network connectivity. Set up IBM Cloud Direct Link or VPN connectivity between the on-premises environment and Power Virtual Server. Direct Link is preferred for larger data sizes as it provides dedicated, high-throughput connectivity without using the public internet.
4. Configure and start migration. Use the Db2 Mirror GUI to configure the migration pair, selecting the appropriate migration method (partition mirroring, assisted save and restore, or manual migration). The GUI guides you through source authentication, copy node setup, and data replication configuration.
5. Monitor data synchronization. Track real-time status of data synchronization through the Db2 Mirror GUI while the production system remains fully active. MWA continuously replicates changes from the source to the copy node on Power Virtual Server.
6. Test the target environment (optional). If using partition mirroring, enter test mode to bring the copy node on Power Virtual Server up to a usable state. Validate applications, configurations, and performance before committing to the final cutover.
7. Perform final cutover. When ready, initiate the final cutover. The source system enters a restricted state briefly while the last set of changes is applied to the copy node. The target system on Power Virtual Server is then brought online as the new production environment.

Network considerations for Power Virtual Server migrations

Network connectivity is a critical factor in MWA migrations to Power Virtual Server. The protocol used by partition mirroring to transfer data from the source node to the copy node is not encrypted. An alternative form of protection or encryption must be used instead, such as physically restricting access to the servers, adapters, and cables or using a virtual private network (VPN) between the nodes.

IBM Cloud Direct Link

The preferred option for MWA migrations to Power Virtual Server. Direct Link seamlessly connects on-premises resources to IBM Cloud and provides consistent, high-throughput connectivity without using the public internet. This is especially important for large data transfers during the initial synchronization phase.

VPN connectivity

When Direct Link is not available, VPN connectivity provides a secure alternative. This approach is suitable for smaller data sizes or environments where dedicated connectivity is not feasible.

Port requirements:

Configure your firewall to allow incoming packets on the following network ports between the source and copy node:

Software requirements

The following software products and options must be installed on the source node before beginning the migration:

Open-source packages required on the source node:

PTF group requirements:

Install the latest level of the following PTF groups before beginning the migration:

Licensing and subscription options

IBM® i Migrate While Active is a Licensed Program Product (LPP) ordered via AAS/e-config/iERP. The license is required only on the source system, not the copy node. Subscription options include:

• 90-day term
• 1-year through 5-year subscription terms
• Default term follows the Expert Care term (3 years); you can select "No Expert Care" for shorter terms
• A 28-day evaluation period is available before a key is required, allowing organizations to download and assess the product before purchasing

Understanding Virtual Serial Numbers

Traditionally, IBM® i software and ISV application licenses are assigned to the physical serial number of the Power server. This means that when a partition moves to different hardware, the software licenses must be reassigned or repurchased, a process that is time-consuming and costly.

Virtual Serial Numbers address this limitation by allowing IBM® i software and keys to be assigned to a virtual serial number instead of the physical hardware serial number. Each partition can have its own unique virtual serial number that is not tied to the underlying hardware, enabling the partition to move across systems without triggering relicensing requirements.

VSN was initially introduced for on-premises Power servers in January 2022 and is applicable to Power9 and Power10 servers running IBM® i 7.2 through 7.5. With the December 2024 release, VSN support has been extended to Power Virtual Server.

Why VSN matters for Power Virtual Server

ISV software licensing flexibility

Eliminates the need to relicense hardware-bound ISV software when virtual machines are moved within Power Virtual Server. Software licenses stay tied to the virtual serial number, not the physical infrastructure, reducing cost and administrative burden.

Elimination of hard pinning

Without VSN, IBM® i VMs on Power Virtual Server may need to be pinned to specific physical hosts to maintain software licensing compliance. VSN removes this constraint, allowing VMs to be placed on any available host without planned outages for license reassignment.

Simplified support and entitlement management

The Power Virtual Server Service Broker connects IBM® Entitled Systems Support (ESS) and iERP with customer and VM details. This integration provides automated inventory management and streamlines the process of tracking software entitlements in the cloud.

How VSN works on Power Virtual Server

When deploying new IBM® i virtual machines on Power Virtual Server, a Virtual Serial Number is automatically assigned (with an opt-out option available). The following aspects describe how VSN operates in the Power Virtual Server environment:

• Automatic VSN assignment: New IBM® i VMs deployed on Power Virtual Server receive a VSN automatically. You can opt out if you prefer to use the hardware serial number.
• One-time account mapping: A one-time mapping of the IBM Cloud account ID to the IBM® ESS customer number is required. This mapping enables the Service Broker API to communicate with ESS/iERP for inventory management.
• Assignment to existing VMs: VSN can be assigned to existing IBM® i VMs on Power Virtual Server. This process requires a shutdown and power on of the VM.
• VSN retention: When deleting a VM, customers can choose to retain the used VSN for future reassignment.
• VSN management through GUI: The Power Virtual Server GUI provides a view of available VSNs and edit options for managing VSN associations.

VSN restrictions on Power Virtual Server

The following restrictions apply to VSN in the Power Virtual Server environment:

• You cannot select a specific VSN or bring a VSN from an on-premises environment to Power Virtual Server.
• You cannot bring software entitlements or subscriptions from an on-premises VSN environment to Power Virtual Server.
• The one-time mapping between the IBM Cloud account ID and the IBM® customer number must be completed before VSN features can be used. Errors will occur if this mapping is not configured.

Planning your migration

Before beginning a migration with MWA and VSN, consider the following factors:

Environment assessment

Evaluate your current IBM® i environment, identifying all critical applications, data volumes, dependencies, and ISV software with hardware-bound licenses. Document any independent ASPs (IASPs) that will need to be migrated separately using PowerHA geographic mirroring.

Downtime tolerance

Determine how much downtime is acceptable for the final cutover. MWA significantly reduces the cutover window compared to traditional methods, but the exact duration depends on the volume of changes accumulated since the last synchronization, the network bandwidth between source and target, and the number and size of objects being tracked.

Network bandwidth

Assess the available network bandwidth between your on-premises environment and Power Virtual Server. Direct Link is recommended for production migrations, especially with larger data sizes. Plan for both the initial bulk data transfer and the ongoing change replication bandwidth.

Software licensing inventory

Catalog all IBM® i and ISV software licenses, noting which are tied to hardware serial numbers. Plan the VSN assignment strategy for the target Power Virtual Server environment and coordinate with ISV vendors as needed for license transfer procedures.

Target environment sizing

Right-size the Power Virtual Server environment to match or exceed the performance requirements of the source system. Use metrics such as CPW (Commercial Processing Workload) for IBM® i workload capacity planning. Power Virtual Server resources can be scaled after migration to optimize cost and performance.

Migration process with MWA and VSN

The following end-to-end process describes how to combine MWA and VSN for a migration from on-premises to Power Virtual Server:

1. Preparation
   • Complete an assessment of the existing IBM® i environment, identifying all critical applications, data, and dependencies.
   • Install the required MWA software and PTF groups on the source node.
   • Provision the target environment in Power Virtual Server, ensuring compatibility with the source IBM® i system.
   • Configure VSN by completing the one-time IBM Cloud account to ESS customer number mapping.
   • Set up network connectivity (Direct Link or VPN) between the on-premises environment and Power Virtual Server.
2. Configure the migration
   • Log in to the Db2 Mirror GUI and add a new pair to the dashboard.
   • Select IBM® i Migrate While Active and choose the appropriate migration method (partition mirroring, assisted save and restore, or manual migration).
   • Complete the Source Authentication step by providing the source node hostname, username, and password. Click Validate source node to verify network connectivity and software requirements.
   • Complete the Copy Node Setup, including installing LIC on the copy node, configuring the service tools server LAN adapter, and starting partition mirroring.
3. Data synchronization
   • MWA begins replicating data from the source to the copy node on Power Virtual Server.
   • Monitor the progress through the Db2 Mirror GUI, which shows real-time synchronization status.
   • The source system remains fully operational during this phase, with all production workloads continuing to run.
4. Pre-migration testing (optional, partition mirroring only)
   • Enter test mode to bring the copy node up to a usable state with a unique IP address.
   • Validate applications, configurations, and performance on the Power Virtual Server environment.
   • The source node continues running production workloads during test mode while disk changes are tracked on both sides.
   • Exit test mode when satisfied. MWA will resynchronize the copy node with the source, undoing test changes on the copy and migrating tracked production changes from the source.
5. Final cutover
   • When ready, initiate the final cutover through the Db2 Mirror GUI.
   • Review and confirm the configuration before proceeding.
   • The source system enters a brief restricted state while the last set of changes is applied.
   • The copy node on Power Virtual Server completes the role swap and comes online as the new production system.
   • Assign or confirm VSN assignments on the target Power Virtual Server VM to ensure software licensing continuity.
6. Post-migration validation
   • Verify that the restored environment on Power Virtual Server matches the on-premises setup, with all configurations and data intact.
   • Confirm that ISV software licenses are properly associated with the VSN on the new VM.
   • Implement monitoring tools to ensure that the new environment operates smoothly and address any issues promptly.
   • Establish backup, high availability, and disaster recovery strategies for the Power Virtual Server environment.

Security considerations

When migrating to Power Virtual Server with MWA, security must be addressed at multiple levels:

Browser connection to the Db2 Mirror GUI

It is recommended to configure the Db2 Mirror GUI for HTTPS by using the IBM® Web Administration for i GUI to manage the ADMIN3 application server and configuring TLS.

Data transfer encryption

The protocol used by partition mirroring to transfer data from the source node to the copy node is not encrypted. Use VPN or physically restrict access to the network path between the nodes to protect data in transit.

User authority requirements

A user must have the following special authorities on the source node to configure and manage partition mirroring: *SERVICE (or authorization to QIBM_QYAS_SERVICE_DISKMGMT function usage identifier), *JOBCTL, *ALLOBJ, and *SECADM.

Cryptographic services configuration

You must configure and load cryptographic services master key 1 on the GUI node for Migrate While Active to store passwords used during migration.

Cutover types

MWA supports two types of cutover, depending on whether IP addresses need to be migrated from the source node to the copy node:

Cool cutover

The source node is put into restricted state from the console and a set of instructions is followed to perform the cutover process. A cool cutover must be used when migrating IP addresses from the source node to the copy node during test mode or final cutover.

Warm cutover

The cutover starts after quiescing the source node. The initiation of new database transactions is halted while waiting for pending database transactions to reach a commit boundary. If the source node fails to reach a quiesced state within the specified timeout, transactions will resume on the source node and the cutover will fail. A warm cutover can be used when starting test mode or during final cutover when IP addresses are not migrated from the source node to the copy node.

Migration process

1. Preparation: Assessed the existing IBM® i environment, cataloged all ISV software licenses, and provisioned a matching Power Virtual Server environment with VSN enabled. Established IBM Cloud Direct Link for high-bandwidth connectivity.
2. Partition mirroring setup: Configured MWA with partition mirroring through the Db2 Mirror GUI. The initial storage synchronization completed over Direct Link while the production system continued running.
3. Pre-migration testing: Used MWA test mode to bring the Power Virtual Server copy node online with a unique IP address. Conducted full application testing and regulatory validation over a two-week period.
4. VSN configuration: Confirmed VSN assignments on the target Power Virtual Server VM and coordinated ISV license transfers to the virtual serial numbers, eliminating the need for relicensing.
5. Final cutover: Scheduled the cutover during a planned maintenance window. The final synchronization and role swap completed in under 30 minutes, far less than the multi-day outage that traditional methods would have required.

Results

Minimal downtime

The migration was completed with less than 30 minutes of production downtime, compared to an estimated 12-18 hours with traditional save-and-restore methods.

Licensing continuity

VSN eliminated the need to relicense ISV applications, saving significant cost and administrative effort. Software licenses transferred seamlessly to the new Power Virtual Server environment.

Risk reduction

Test mode allowed thorough validation of the target environment, including regulatory compliance testing, before the final cutover. No issues were discovered during the actual migration.

Operational efficiency

The Power Virtual Server environment provided improved scalability and the pay-as-you-go model optimized operational costs, reducing the overall IT spend by transitioning from capital to operational expenditure.