Kyndryl Cloud Uplift Debuts in Canada: Move IBM Power Workloads to Azure Securely

Background / Overview​

Why Canada matters: data residency, regulation and enterprise risk​

What Kyndryl Cloud Uplift actually does — technical breakdown​

• Support for IBM Power families and their primary operating environments: AIX, IBM i, and Linux on Power. This enables customers to move workloads that often cannot be easily rewritten or containerized.
• Integration with Microsoft Azure infrastructure and networking constructs. Skytap / Kyndryl Cloud Uplift runs on Azure host infrastructure (including options that map to Dedicated Host capabilities in Azure), and the platform provides documented regions and API names for Azure‑hosted deployments (for example, a Canada/Toronto region name).
• Network connectivity and hybrid options: customers can use ExpressRoute to create private circuits between on‑premises estates and Kyndryl Cloud Uplift on Azure, enabling consistent latency and control during lift‑and‑run scenarios. The platform’s documentation includes procedures for using customer‑managed ExpressRoute circuits.
• Self‑service tooling for “lift, run, and modernize”: the original Skytap heritage emphasizes templates, cloning, snapshots and lab‑style environments that let teams test and modernize incrementally without long outage windows. That capability remains central under the Kyndryl Cloud Uplift brand.

Strengths: what Canadian IT teams can realistically expect​

• Lower migration risk — By enabling “as‑is” replication of IBM Power workloads, Cloud Uplift dramatically reduces the project risk and timeline compared to full refactoring or rewrite programs. For systems where change is too risky (billing, transactional back ends, regulatory systems), this is compelling.
• Data residency and compliance alignment — Running inside Microsoft’s Canadian regions helps organizations satisfy data‑residency requirements and simplifies controls for auditors and regulators. For many public‑sector buyers and regulated financial firms, this is a gating requirement.
• Speed to value — Self‑service templates, cloning and testing environments let teams validate migrations, run acceptance tests and start to modernize peripheral services (for example, front‑end microservices or analytics) without prolonged cutovers. Kyndryl positions Cloud Uplift as a way to get workloads into Azure quickly and then modernize incrementally.
• Enterprise support and managed services — Kyndryl’s global services footprint and Azure partnership mean customers can combine the platform with Kyndryl’s advisory, implementation and managed services — useful for organizations lacking internal skills for Power‑to‑cloud moves.
• Path to Azure‑native capabilities and AI — Once workloads run inside Azure, organizations can integrate them with modern services — storage tiers, identity, telemetry, and Azure AI services — on their own timelines rather than being forced to replatform upfront. This incremental modernization model reduces disruption.

Risks, caveats and what to watch for​

• Licensing and software entitlements — IBM Power environments often come with complex ISV licensing and IBM support entitlements. Moving a workload from on‑premises to cloud—even if “as‑is”—can have licensing, support and audit implications. These costs are vendor‑specific and must be validated with IBM and ISV contracts before migration. Kyndryl help docs and datasheets do not remove the need for license verification.
• Cost dynamics: infrastructure, egress and network topology — Running bare metal or dedicated host instances for Power workloads in Azure can be expensive. Additionally, organizations that intermix Canadian and non‑Canadian resources may face cross‑region egress fees and interconnect complexity. Plan for application‑level traffic patterns and test cost models in proof‑of‑concepts. Azure’s zone/region billing and ExpressRoute models mean egress and connectivity must be carefully modeled.
• Performance and latency expectations — Even when running in the same country, cloud networking and hypervisor behaviour differ from traditional on‑prem Power estates. Performance testing against representative workloads (peak I/O, batch windows, interdependent services) is essential before committing to a production cutover. Kyndryl’s self‑service cloning and lab features can help, but they do not replace full production‑scale load tests.
• Operational model changes — Running legacy stacks in Azure changes operations: telemetry platforms, patching windows, backup and DR patterns, and incident management will need re‑tooling. Teams should budget time for runbook updates, SRE adjustments and security baseline alignment.
• Sovereignty vs. regulatory nuance — “Data in Canada” satisfies many barometers, but regulatory regimes can require more than physical residency (e.g., control over encryption keys, government access, or specific certifications). Organizations must verify that running on Microsoft Canada plus a third‑party commercial offering meets their specific legal and procurement requirements. Don’t assume residency solves all compliance questions automatically.
• Vendor lock and long‑term modernization — Lift‑and‑run is an excellent near‑term risk reduction tactic, but it can delay essential modernization. Teams must maintain a clear roadmap from “lifted legacy” to an eventual refactor or replatform where it makes business sense, otherwise technical debt can simply migrate to the cloud.

Practical migration checklist: planning to production​

• Inventory and categorize workloads:
• Identify IBM Power systems by OS (AIX, IBM i, Linux) and dependent services.
• Classify criticality, peak I/O, and maintenance windows.
• Validate licensing and ISV agreements:
• Engage IBM and ISV partners to confirm licensing portability, support, and audit rules for cloud hosts.
• Define compliance and residency requirements:
• Document regulatory obligations (data residency, encryption, access controls) and map to Azure Canada region controls and Kyndryl controls.
• Establish network architecture:
• Design ExpressRoute or equivalent private connectivity; account for bandwidth, latency, and egress pricing.
• Ensure IP planning, DNS and security posture alignment.
• Run a proof‑of‑concept:
• Use Kyndryl Cloud Uplift’s lab/clone features to replicate representative workloads.
• Perform functional, performance and failover testing.
• Plan cutover and rollback:
• Define a stepwise cutover (pilot apps → non‑critical production → critical systems).
• Maintain clear rollback criteria and automated snapshots.
• Integrate telemetry, security and backup:
• Implement centralized logging, monitoring and SRE runbooks.
• Configure backup targets, retention, and DR plans that reflect in‑country SLAs.
• Modernization roadmap:
• Identify candidates for eventual replatform, containerization or data‑service migration.
• Schedule incremental modernization sprints once workloads are stable in Azure.

Costs and commercial considerations​

• Compute cost for Azure Dedicated/Host instances or bare‑metal mapping used to present IBM Power environments.
• Storage costs (including tiering for backups and snapshots).
• Network costs (ExpressRoute provisioning, cross‑region traffic, and any egress charges).
• Managed services and migration engineering fees from Kyndryl or partners.
• ISV and IBM licensing adjustments.

Integration with Azure-native modernisation and AI​

• Pairing transactional backends with Azure analytics and data platforms for enhanced reporting and AI‑driven insights.
• Exposing legacy functionality via API gateways or microservice facades to enable modern UX or SaaS front ends.
• Migrating non‑critical surrounding functions to Azure PaaS (databases, caching, telemetry) while keeping core processing on Power.
• Using Azure AI and MLOps pipelines to augment business processes without changing core transactional systems immediately.

Realistic timelines and success metrics​

• Small pilots and labs: 2–6 weeks
• Pilot production migration for non‑critical workloads: 1–3 months
• Full production migration for critical systems (including extensive testing and regulatory sign‑offs): 3–12 months, depending on complexity

• Recovery Time Objective (RTO) and Recovery Point Objective (RPO) adherence in the new environment
• Application transaction throughput and latency relative to on‑prem baselines
• Compliance audit pass rates for in‑country residency requirements
• Total cost of ownership (TCO) and run‑rate comparison after 12 months
• Measured time to enable a first Azure‑native capability (for example, exposing an API or integrating a data pipeline)

Case for and against: when Cloud Uplift is the right move​

• You run critical IBM Power workloads that are costly or risky to refactor.
• Regulatory, procurement or political constraints make in‑country data residency essential.
• You want to accelerate time‑to‑cloud while keeping operations intact and have a plan for incremental modernization.
• You need enterprise‑grade managed services and support during the migration.

• You have a greenfield or cloud‑native stack where replatforming yields better long‑term cost and agility.
• Your team is already undertaking a planned, funded rewrite with clear ROI that outweighs short‑term lift benefits.
• The ISV or IBM licensing model prohibits cloud portability or imposes prohibitive costs.

Vendor and independent verification — what the documents show​

Recommendations for Canadian CIOs and IT leaders​

• Start with a short, accountable pilot: pick a non‑critical but representative IBM Power workload to prove performance, networking and cost assumptions inside Azure Canada.
• Lock down licensing early: engage IBM and your ISV partners before any move to understand entitlements and avoid audit surprises.
• Treat residency as a program, not a checkbox: confirm encryption, key management, and contractual controls that reflect your compliance requirements.
• Model network costs and DR: don’t underestimate egress, cross‑region traffic, and multi‑region DR implications.
• Plan a modernization runway: use Cloud Uplift to remove the immediate migration barrier, but maintain a concrete 18–36 month modernization roadmap to avoid replicating technical debt in the cloud.
• Use managed services strategically: where in‑house Power and Azure experience are limited, combine platform lift with vendor or partner managed services to accelerate learning and reduce risk.

Final analysis: practical bridge, not a final state​