Think Your On-Prem App is Cloud Stubborn? Think Again!

At some point, we’ve all heard the phrase: “My app can’t be moved to the cloud…it’s based on AIX or IBM i.” These words often come from application owners who don’t want to re-engineer their application to use cloud-native services; they’d much rather do a classic lift-and-shift to move their application without any code changes. While some claim it’s an anti-cloud method to do a straight lift-and-shift without making use of cloud-native services, there are some instances where migrating to the cloud without changing application infrastructure makes sense. These include:

• Development: If the business is growing, there’s a chance it’ll need more sandbox space for developers; rather than expanding on-premises resources, they can leverage the cloud instead.
• Disaster Recovery: Run the DR systems in the cloud instead of having another physically separate customer-financed data center to host a disaster recovery architecture. The DR system must “look and operate” the same as the on-prem system for this to work effectively.
• Test: Due to new initiatives or even old quality issues, there’s a need for additional test systems that act like production. Instead of broadening on-prem assets, developers turn to the cloud, but they need ‘Test’ to look like on-prem ‘Prod.’

Since IBM i (AS/400) and AIX are based on PowerPC and not x86, the route to AWS, Azure, or Google Cloud is not apparent for these kinds of apps. They are “cloud stubborn.” 

What if leadership or the IT team overall wants to reduce costs by moving resources outside the data center? Perhaps a data center lease is expiring, and the team must decide if they want to renew or find a different way to host critical applications. If core apps are based on IBM i (AS/400) or AIX, what are some options? 

In most cases, the question is: “How can I move my application ‘somewhere’ to give it cloud-like capabilities without having a prerequisite of rewriting the application into cloud-native services?” 

As it turns out, there are multiple options for moving legacy apps from IBM i (AS/400) or IBM AIX (PowerPC based) to the cloud, including:

1. IBM Power Systems available on Google Cloud 
2. Microsoft brings IBM iron to Azure for on-prem cloud migrations
3. Power on IBM Cloud

Clearly, there are solutions for those who believe their app can’t run in the cloud. In all fairness, though, a basic lift-and-shift isn’t exactly applicable here. I’ve worked on several projects where we successfully moved the app in question to the cloud from IBM i or AIX and had it run without making application logic changes. Unfortunately, the path to get there requires some re-engineering because the entire data center infrastructure has not been migrated to the cloud.

One of these roadblocks to migration involves storage. On-prem there’s a Storage Area Network (SAN) where one can create storage volumes assigned to logical partitions (LPARs) or virtual machines. The SAN comes from a specific vendor, and there’s available storage or IT team that only cares for that single on-prem architecture component.

In the cloud, users must use their cloud vendor’s storage architecture. Storage is generally abstracted so one never works directly with disk drives and arrays. IT teams still build storage units Logical Unit Numbers (LUNs) assigned to cloud-based servers, but that route will be different than doing it on-prem. Resource assignments for storage and networking will operate differently under the hood. But all the “in guest” storage objects can be called the same way as they were on-prem, so ultimately the application will run the same.

The result is the on-prem app can theoretically run “un-changed” in the cloud from a functionality standpoint, but the migration process will require some re-alignment of resources and techniques.

Once the stubborn IBM i or AIX application is in the cloud, users can apply “cloud flexibility” to it. For instance, one can “clone” a server or a collection of servers and have them run in a private sandbox. The sandbox or “environment” is akin to its own virtual data center and two environment clones with the same hostnames, IP addresses, and even MAC addresses, don’t collide because they don’t see each other on the same network space.

As a result of this cloud flexibility, developers can create production, developer, QA, and resiliency test environments. Each runs independently, not seeing or impacting the rest.

It is now possible to migrate “cloud stubborn” apps like IBM i (AS/400) or AIX to the cloud. This likely won’t be the best fit for every traditional application, but I’d urge IT departments to research the options listed above to see what is viable for their portfolios. Every major player in the cloud offers a path for IBM i and AIX; the impossible is now possible.