App Migration: The Light at the End of the Tunnel is Closer Than You Thought

The modern application can be quite a complex beast.  Some applications are self-contained in one huge binary (or more likely a collection of binaries) working together.  It is surprising how many times I encounter someone struggling in a customer service scenario with a ‘green screen’.  They fill in the blanks on the screen by pressing all sorts of function keys.  These applications are often distinguished by the frustration of the individual cursed by having to interact with it.  The logic and the data of the application are all in the binary and associated data store.  This application architecture has mostly been found in mainframes with transaction processors like CICS controlling the action.

Other applications are still part of the older Client Server architecture, where the backend is a database server supporting clients running on desktop computers. Here, the logic and data are in a back-end database. The logic is invoked by the clients running executables on the backend server. The backend server in this architecture has to be big enough to run the database and all of the client processes.   The Oracle Applications 10.2 is a good example of this architecture.  As for hardware, this architecture drove the sales of ever larger and more powerful backend UNIX SMP servers.  Processing threads and memory made this application run efficiently.

Client Server Applications

I consider other modern applications a variant of the Client Server, in that the back-end database is still there holding all the data but the clients have changed to web servers that support the users interacting with the application using browsers.  Logic is now running in the web servers on smaller Linux or Windows boxes but the application is still beholden to a big backend SMP UNIX or Linux server.  Examples of this sort of application are SAP and Oracle Applications 11.


There are the ‘XaaS’ applications.  Add your favorite letter in place of the X such as an ’I’ for Infrastructure or an ‘S’ for Software.  These applications can have multiple databases, as well as other data sources like data from the web to support the application.  In this architecture, there is no one backend database controlling the application.  The logic of the application is in the web servers that make up the application.  The application gets data from multiple services.


Sometimes, the application servers and database servers are all co-resident in the same server.  Each application is segregated from the others using a form of virtualization in big UNIX servers, such as AIX LPARs or Solaris Containers.


All of these application types lead to different migration procedures.  This doesn’t mean that the migration steps for each type on the migration spectrum are different here.  Each component in the architecture running on a big UNIX (RISC) or mainframe server needs to be migrated separately.  In other words, whether the middle tier is on a discrete hardware platform or on a virtualized server, move the applications in each tier separately as a distinct effort.   By breaking it down into the distinct parts, the process can be completed with less risk to the overall application.

Migration of Client Server

This may prove to be the most challenging migration.  I’ve had a lot of experience here as this was the predominate architecture of systems into the mid-90’s.  This architecture has the application code and the data store on the same server.

This migration presents a number of temptations. The temptation to update the application system to multi-tier web based systems.  The temptation is to upgrade at the data store at the time of the migration (then again, if you are running on Oracle 9i or Oracle 8, then maybe you have to upgrade because the new system cannot host these older versions!). Another temptation is to ‘fix’ problems with the application system. If you can’t resist the temptations, then add several weeks/months to the migration plan.

If you haven’t succumbed to the temptations, then this migration includes some of the steps in the code conversion migration methodology (for the application systems) AND the steps found in the data base migration methodology. All of this has to be done concurrently to minimize any outage. This requires a lot of testing and planning to ensure the migration steps converge together at the proper time.

An example is an Oracle database with a custom application system accessing the data.  The first step would be to convert the application system (shell scripts, PERL, make files, OCI programs, etc.) on a test platform and proof it. Then, test the conversion of the database to the target system and possibly the new version of the database. If it is possible, upgrade the database on the legacy platform first.

Migration of a Multi-Tier Application

This application architecture has a web tier that faces the world, an application tier that contains the application logic, and is in between the web tier and the data store tier. The data store tier hosts all of the data supporting the application and is usually a commercially available database server like Sybase, Oracle or DB2 (if it is SQL Server, then your work is done for this tier).

This migration may be close to finished already.  Often, the web tiers and application tiers already run on Intel based servers.  Other configurations will have the tiers in virtual machines in one large server, such as LPARs in an AIX server.

In the first case, where only one or two tiers run on legacy servers, the migration would resemble the client server but with the isolation of the application systems from the other tiers, it can be migrated separately. The migration process would be:

  1. Migration of the web tier to Linux servers.
    1. Install the native Linux version of the Web Server program and modify
    2. Use these web servers for the production application.
    3. Migration of the application tier
      1. Install a native Linux version of the application or
      2. Convert the application using the code conversion methodology
      3. Use these application servers for the production application.
      4. Migrate the database using the database migration methodology

Migration of Cloud Services

Not all services supporting cloud services run on Intel hardware. Some run on mainframes, and others on legacy UNIX servers. Determining the numbers, effort and sequence of the migrations of these services is part of the initial analysis of the systems.

Tackle each one following the appropriate methodology. Bring them online individually to avoid the problems associated with adding too many variables when determining solutions to problems.

The point here is to demonstrate that the UNIX or Mainframe to Linux migration methodologies are modules that can be combined or called upon as needed to migrate applications. The savvy manager can add these to the overall migration plan.

Here’s to your successful upgrading of your application infrastructure!