The Cloud Dilemma

What to do with traditional on-prem applications that don’t appear to have a path to the cloud?

“My app can’t be moved to the cloud… is based on AIX or IBMi…….”

What is implied is that the app owner doesn’t want to re-engineer their application to all use cloud-native services, but instead wants to do a classic lift-and-shift of their application without making any application code changes. Since IBMi (AS/400) and AIX are based on PowerPC and not x86, the path the cloud is not apparent for these types of applications.

The motivation is based on the desire to avoid new costs of expanding existing datacenter resources, or there is motivation to reduce costs by shifting resources out of the datacenter. One example might be that your data center lease is expiring, and you have to either renew it or find an alternative model for hosting your critical applications. If your core applications are based on IBMi(AS/400) or AIX, what options do you have?

It does appear that these types of applications would be cloud-stubborn when thinking about them in the Azure, AWS, Google Cloud mindset, but a new set of services may offer an alternative path. 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.”

Some might say it is an anti-cloud pattern to do a straight lift and shift, but there are legitimate use-cases and reasons why moving to the cloud without changing application structure makes sense:

  1. Disaster Recovery – instead of having an additional geographically separate customer financed data center to host DR infrastructure, run the DR system in the cloud. With the prerequisite being that the DR system “looks and operates” the same as the on-prem system of record.
  2. Development – If your organization is growing, you may need more sandbox space for developers, and instead of expanding on-prem resources, you leverage the cloud.
  3. Test – Because of new initiatives or maybe historical quality problems, you need more test systems that look and work like production. Instead of expanding on-prem resources, you look to the cloud, but you need ‘Test’ to look like on-prem ‘Prod.’

What cloud options exist for running “traditional” applications from IBMi(AS/400) or IBM AIX (PowerPC based)?

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

*** Full disclosure, I work for Skytap. Our company is the underlying cloud engine for Power used in product offerings from both Microsoft and IBM.

So there are options for the “My app can’t run in the cloud….”, but to be fair, a straight lift-and-shift is not entirely accurate. I’ve been involved in several projects where we have been successful moving the application from IBMi or AIX to the cloud and have it run making absolutely “no” application logic changes. But (there is always a ‘but’), the migration path to get there will require some ‘re-alignment’ since you are not moving your entire datacenter infrastructure to the cloud.

One migration friction point is related to storage. On-prem you have a SAN where you create storage volumes that are assigned to LPARs (virtual machines). Your SAN comes from a specific vendor and you have a storage team or a few persons that just care for that one on-prem infrastructure component.

In the cloud, you have the cloud vendor’s storage architecture. In most cases that storage is abstracted and so you never really work directly with disk drives and arrays. You still create storage units (LUNs) that get assigned to your cloud-based servers, but the process will be different than how you did it on-prem. From the perspective of the LPAR running in the cloud, you still end up with file systems, storage pools, etc. All of the “in guest” storage objects can be called the same just like they did on-prem, and because of this your application can run the same way, but under-the-covers, the assignment of resources like storage and networks is different.

The net-net is that your on-prem application can potentially run “un-changed” in the cloud from a functionality perspective, but the migration process will involve some re-alignment of techniques and resources.

But once it is in the cloud, you can apply “cloud flexibility” to your traditional application. For example, you can “clone” a single server or a collection of servers and have them run in a private sandbox. The sandbox or “environment” is like it’s own virtual datacenter 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. And because of this cloud flexibility, you can create production environments, developer environments, QA environments, and resiliency test environments. Each is running in its own world,  not seeing or impacting the others.

There are networking techniques that allow environments of multiple machines to be “cloned” and run simultaneously, but it can and is being done. We’ll cover this in more detail in the future.


It is possible to move “cloud stubborn” applications like IBMi(AS/400) or AIX to the cloud. Maybe not every system in your portfolio is a candidate for this, but it is a viable option that you can investigate. Since all the major cloud players are providing this capability, it is “real” and not fantasy land.