IT Modernization & Data Migration: A Spectrum of Options

I’ve been writing about executing the Proof of Concept for a RISC to IA migration.  I want to step back with this post and present a context for this activity.  The POC is best for migrating a application running in production and for a one-off migration at that.

But what if that’s not what your facing?  What if you are converting your firewall servers from an old RISC based platform to a modern IA server?  The POC seems like a lot of unnecessary work.  I mean, you need to prove out that the use of an IA server in place of the old RISC server works and meets the SLA requirements.

Then again, what if your IT Modernization efforts entail moving your old applications from the old Mainframe to a new IA based server?  The POC in this case is a significantly more involved effort what with code conversions and possibly application replacement on top of porting data.

I’ve developed a spectrum of the types of migrations.  It doesn’t cover every migration type but I’d bet that your IT Modernization effort falls into this spectrum.   Here’s my graphical representation of this spectrum.

R2IA Continuum.jpg

The more replicable migration types include the migration of Infrastructure applications from RISC to IA.  These applications are ones with a native IA port from the vendor.  They are diverse and can be backup and restore applications, firewalls, Web Servers, file and print servers, etc.  This migration consists of testing the application on the new target and measuring performance.  If it measures up then develop a plan to replicate the steps and begin migrating the applications somewhat like a cookie cutter.  The next type of light lifting migration is to move an application that is more complex but is commonly found throughout the enterprise.  Applications in bank branches or retail outlets come to mind.  Migrate one of these in test, document the steps, plan the logistics, and train a cadre to go forth and migrate.   This too is similar to a cookie cutter operation.  The following flow chart captures the tasks:

Pilot Flow.jpg

Next in the spectrum are the more unique migrations that get more complex as the details grow.  From here on out you’ll need to execute a PoC and the migrations tend to be a ‘one-off’ or each migration is a discrete event that frequently doesn’t inform any other migration.   My forthcoming posts to this blog will cover the steps in these migrations in greater depth but right now I just want to briefly touch on the general types that occur.

  • Migrate using the same software stack and same versions.  The software stack varies only to the extent that Linux varies from UNIX.  The other software has ports for RISC and IA and the software on each platform is nearly identical.  Just the data unique to the enterprise needs to be transferred.
  • Migrate using the same software stack and but versions.  The software stack variance is marked by the different versions of the underlying software, for instance Oracle9i on the legacy server and migrating to Oracle11g.  While the software has ports for RISC and IA and the software on each platform no differs enough to add additional complications.  Migration tools available in Oracle11g aren’t available for Oracle9i.  While the data unique to the enterprise needs to be transferred the application code in the database may need conversion to address the differences in the upgrade.
  • Migrations get a lot more difficult with the porting of code written specifically for the enterprise.  This can be C++, C, or even JAVA code that needs to be converted.  Some OEM vendors, HP and IBM, have tool sets for assisting in the migration from Solaris to Linux.  These tools read the source code (you do have the source code, don’t you?) and provide in-line notations where changes need to be made in library calls or syntax.   Often this code conversion effort is long and tedious and is outsourced to a third party.    How many lines of code, 100,000, 400,000, or 1,000,000 is your application you want to migrate?
  • Suppose you want to migrate your application from running on DB2 on AIX to running on SQL Server and Windows 2008 R2.  You are changing the platform, the Operating System, you are changing the database, and you have to modify the program code that runs in the database like stored procedures.  Whew!  A lot of variables here and each needs to be carefully monitored and managed.   This is a complex process and I would recommend converting the overall plan into discrete steps, for instance migrate platforms first and insure that everything works correctly and then move to the new operating system and database.
  • The far right of the spectrum is mainframe migration to IA.  This doesn’t necessarily mean that it is the most difficult or complicated process.  This could be a migration of Oracle on the mainframe to Oracle on an IA platform and this would follow the process outlined above.  Other applications on Mainframes can be 50 years old or more.  These are the applications that bring the greatest challenges.   This would likely involve a complete application re-write and then we’re into application development which is a topic for another series of blogs.

Overall the migration processes are all challenging in their own way but the rewards of lower costs and better utilization of Data Center resources, electricity, cooling and floor space, make the journey worth the adventure.