Talk to any IT leader still running AS400 on-premises and a few things come up again and again.
- The first is people
The engineers who understand RPG, CL, and the object-based architecture underneath it are retiring, and few new graduates are learning the platform. Every year that gap widens, and every year the cost of keeping a skilled team in place climbs higher.
- The second is cost structure
Proprietary hardware, IBM i licensing, and specialist support staff add up to a fixed, front-loaded expense that only grows as the hardware ages. There is no way to scale that cost down during quiet periods, and no way to avoid a large capital outlay when the hardware finally needs replacing.
- The third is integration
Modern businesses run on data that moves constantly between ERP, CRM, ecommerce, and analytics platforms. AS400's monolithic structure was never designed for that kind of exchange, so every new integration becomes a custom project involving middleware, batch exports, or screen-scraping instead of a straightforward API call.
- The fourth is security posture
AS400 has strong built-in controls, but the surrounding compliance tooling, encryption standards, and threat detection that regulators now expect were built for a distributed cloud world, not a single-box mainframe. Meeting HIPAA, PCI DSS, or SOX requirements on aging infrastructure takes more manual effort every year.
None of this means AS400 is a bad system. It means the infrastructure underneath a genuinely strong application no longer matches how the rest of the business operates.
AS400 to Azure Migration Process
An AS400-to-Azure migration does not usually mean rebuilding the whole system from scratch. In a lift-and-shift approach, the existing IBM i environment is moved onto IBM Power infrastructure hosted in Azure, so much of the existing application can continue to run as it does today.
1. Understand what needs to move
The first step is to look at the existing AS400 environment and identify the applications, databases, integrations, users, batch jobs, and other systems that depend on it.
This helps determine what needs to move together and what needs to be reconnected after the migration.
2. Prepare the new IBM i environment in Azure
A new IBM i environment is then created in Azure.
The important part is that the applications are still running on IBM Power infrastructure. The business is changing where the system runs, not automatically replacing the applications themselves.
3. Back up and move the existing system
The current AS400 environment is backed up, including the applications and data that need to be migrated.
That backup is then securely transferred to Azure. Microsoft’s reference architecture uses standard IBM i backup tools and Azure storage to move the system.
In simple terms:
Take a copy of the existing system → move it to Azure → restore it there.
4. Reconnect everything around it
Once the AS400 environment is running in Azure, the surrounding systems need to be connected again.
That can include:
- users
- ERP applications
- warehouse systems
- reporting tools
- partner systems
- APIs
- printers and batch processes
This is an important part of the migration because the AS400 rarely works alone.
5. Test everything before switching over
Before the old environment is retired, teams test the new one to make sure applications, data, integrations, users, reports, and scheduled jobs are working correctly.
Once everything is validated, the business switches production activity to the Azure-hosted environment.
The old system can then be kept temporarily as a fallback or retired once the migration is stable.
What AS400 to Azure Migration Actually Brings
Moving AS400 workloads to Azure does not mean throwing away the applications your business already relies on. The value is in removing the infrastructure problems around them while keeping the business logic intact.
Aging hardware stops dictating your roadmap
One of the biggest pressures with AS400 environments is the hardware itself. Systems may still run reliably, but upgrades, maintenance, capacity planning, and replacement cycles become harder to justify over time.
Moving to Azure shifts that burden away from physical infrastructure. Businesses can keep their IBM i workloads running without having to plan every future requirement around another on-premises hardware purchase.
You do not have to rewrite everything just to modernize
A full application rewrite can turn modernization into a multi-year project.
With options such as Skytap on Azure, existing IBM i applications, RPG and CL programs, databases, and established workflows can move with little or no change to the underlying application code.
That means the business can modernize the infrastructure first without putting proven application logic at unnecessary risk.
Capacity becomes easier to manage
On-premises systems force businesses to plan for peak demand long before that capacity is actually needed.
That often means either paying for more infrastructure than the business normally uses or struggling when workloads suddenly increase.
Cloud-based infrastructure gives teams more flexibility to adjust resources for seasonal demand, month-end processing, growth, testing, or temporary workload spikes without buying another physical server.
Disaster recovery becomes less dependent on a second data center
Traditional AS400 disaster recovery can require additional infrastructure, replication planning, and a separate environment that may sit idle most of the year.
Azure provides access to cloud-based backup, replication, snapshots, and recovery options that make it easier to build resilience around critical IBM i workloads.
The goal is not simply to move the same recovery setup into the cloud. It is to reduce how much infrastructure the business has to maintain purely for the possibility of an outage.
Connecting AS400 to newer systems becomes easier
Many AS400 environments become difficult to work with not because the applications have stopped doing their job, but because the rest of the technology stack has moved on.
Cloud migration creates more options for connecting IBM i data and business logic with APIs, analytics platforms, mobile applications, partner systems, DevOps tools, and other cloud services.
Instead of replacing the core system, businesses can make it easier for newer applications to work with it.
Development and testing no longer have to interfere with production
Creating separate environments for development and testing can be expensive or slow when infrastructure is limited.
Cloud-based environments make it easier to create copies, snapshots, and temporary test environments without constantly competing with production workloads.
That gives teams more freedom to test integrations, upgrades, and application changes before they reach the live system.
Infrastructure costs become easier to align with actual usage
Traditional AS400 infrastructure often means large upfront investments followed by years of maintenance.
Moving to Azure changes that model. Businesses can reduce their dependence on large capital purchases and align more of their infrastructure spending with the resources they actually use.
The result is not a different AS400 application. It is the same trusted business logic with fewer of the infrastructure limitations surrounding it.
What Our Projects Have Taught Us
Across the AS400 and cloud projects we have worked on, one pattern keeps coming up: migration problems often start before the move and continue after it if the groundwork is weak.
For a food processing business preparing for AS400 migration, the first priority was documenting processes, dependencies, data flows, and business logic so the team knew exactly what had to be preserved during the move.
For an iPaaS provider dealing with cloud integration issues, the challenge came after systems were already in the cloud. The focus was on standardizing data exchange and making sure connected applications could communicate reliably.
A few lessons stand out:
- Understand the current AS400 environment before moving it.
- Document dependencies, integrations, and business rules early.
- Do not assume the job is done once the workload reaches the cloud.
- Make sure the migrated system still connects cleanly with everything around it.
The takeaway is simple: a successful migration depends on getting both ends right, what you are moving and how it will work once it gets there.
Ready to Move? Get the Support Right First
An AS400 to Azure migration is only as good as the planning behind it and the support that follows. The environment needs to be assessed properly, the right migration path has to be chosen, and the system still needs to work smoothly once it is live in the cloud.
And that is exactly where Nalashaa fits in
Our IBM i experts help businesses assess their current AS400 environment, define the right cloud migration strategy, move applications and workloads with minimal disruption, and provide ongoing support once the migration is complete. Whether the right path is application re-hosting, moving selected batch jobs, or broader modernization, the approach is built around what makes sense for the business rather than forcing unnecessary change.
Let us help you move your AS400 environment to the cloud without losing the business logic that already works. Make an appointment with us today to discuss your next move
Frequently Asked Questions
What migration approaches are available for moving AS400 to the cloud?
Most migrations fall into rehosting, replatforming, refactoring, replacing, or a hybrid mix of these. Rehosting moves the environment onto cloud-hosted Power infrastructure largely unchanged. Replatforming updates surrounding tools like databases and monitoring while keeping the core logic intact. Refactoring breaks the application into smaller, API-exposed pieces for long-term flexibility. Many organizations phase these approaches across a multi-year roadmap instead of choosing one for the entire estate.
Does migrating to Azure require rewriting RPG or CL code?
No, not for a rehost migration. Because services like Skytap on Azure run genuine IBM Power hardware rather than an emulator, existing RPG and CL programs, along with green-screen interfaces and job routines, typically move over with no code changes. Rewriting only becomes necessary if the organization later chooses to refactor the application into smaller services.
How long does an AS400 to Azure migration take?
Timelines vary with data volume, customization, and how many systems the application touches. A narrow, well-documented application can move in a few weeks to a few months, while a large enterprise system with years of customization and heavy integration can take well over a year. A phased approach, starting with rehosting and layering in modernization afterward, tends to compress the time to first value even on a long roadmap.
Is data secure during the migration itself?
Yes, when the migration path is designed for it. Backup data typically moves from the on-premises IBM i environment through a Data Box Gateway, over a private Azure ExpressRoute connection, through a Private Link endpoint, and into Azure Blob Storage, never touching the public internet along the way. That same private connection carries day-to-day user traffic once the system is live in Azure.
Can Azure Migrate assess an AS400 environment directly?
Not in the way it assesses Windows or Linux servers. Azure Migrate's discovery and assessment tools are built for VMware, Hyper-V, and physical server workloads, along with certain databases, not for IBM Power partitions. For the AS400 environment itself, assessment typically comes from a dedicated migration partner or IBM Power-specific tooling. Azure Migrate still earns its place in a broader project, though, for assessing the surrounding servers, integrations, and applications that sit around the AS400 system and are also moving to Azure.
Is Skytap on Azure secure enough for compliance-heavy industries?
Yes. Skytap on Azure holds SOC 2 and SOC 3 attestations and complies with ISO 27001 and PCI DSS 3.2, on top of the reliability that comes from IBM Power9 systems with RAID 6+1 storage and 10 Gb/sec backplane networking. For regulated industries like banking, insurance, or healthcare, that compliance posture layers on top of Azure's own security controls rather than replacing IBM i's built-in protections.
How much compute capacity can Skytap on Azure handle?
Enough for demanding enterprise workloads. The platform supports up to 44,000 CPWs and 512 GB of RAM per environment, with pay-as-you-go pricing that lets organizations size logical partitions to the workload instead of buying headroom they may never use.
Does moving to Skytap on Azure mean giving up on-premises IBM i entirely?
No. Organizations can keep critical systems of record running on-premises while migrating other workloads to Azure, or move everything and modernize using native Azure services like advanced analytics and machine learning once the data is there. The architecture supports both a hybrid approach and a full cloud move, and the right one depends on the organization's own timeline and risk tolerance.
