Key decisions of a complex application migration


A complex application migration

Normally an application migration is focussing on moving or upgrading an application and its associated interfaces. Also the supporting and underlying ICT infrastructure is part of a migration. This type of migration can still be very complex. Certainly when you take into account that disruption of applications and its surrounding environment must be avoided. This applies especially to Managed Hosting en Cloud environments. But imagine three-hundred applications must be migrated due to severe external reasons!

High KPI’s

Now imagine you have to move AND upgrade three-hundred applications whereas some of these applications are highly critical to the business with a Service Level Agreement set to 24/7 99,99% RPO is zero and RTO less than minutes?  And on top of that you have limited resources, time and budget! This is virtually impossible! And yet it has to be done!

Principles

  • The main principle of the application migration project is to move all the applications, ICT-infrastructure and all other equipment from datacentre A and B to datacentre C and D within a very limited time frame..
  • The other principle is to upgrade the stack from OS, database up to the application.
  • Another principle is to reduce the amount of applications and according interfaces.

Knowledge is knowing!

“How should you proceed?” we asked ourselves as a project team. Magic doesn’t help only a thorough and well planned investigation of the total application landscape and underlying ICT infrastructure is the starting point. And for that all stakeholders must be involved from system engineers, application managers, migration specialists, developers up to external suppliers specialists. Also the documentation from  operational manuals up to the designs showing the details and dependencies of all the applications.Furthermore a 100% reliable Configuration Management Database (CMDB) was extremely required.

Encountering the long-living operational hurdles

So we did the first step and we already hitting the wall. Bad or no documentation regarding the applications.and ICT infrastructure. No reliable CMDB; a reliability of 85%. Due to years of cut backs, personnel was gone and none-core tasks were outsourced to several parties who had their own administration, own responsibilities but most of their own headaches because their contracts were being terminated soon. So how do you move and upgrade applications on such scale with so many issues? What scenario can you use to migrate? We felt as a team that we are stuck on a jungle seeing no way out. Or we felt like paratroopers who had received a manual just before we were pushed out of our plane and now hanging in the air without knowing how to open it and had only time during our jump to read the manual before we were hitting the ground.

To find a way in a jungle – making key decisions

Needless to say that the project failed two times before it started to get at last results. But these failures were needed to give the project and organisation a lot of valuable information based on our evolutionary insights. Lets be honest, how many businesses are facing this kind of migration!

Based on what we encountered during the first two attempts to move and upgrade the applications we decided to split up the application migration into three parts. So the first project was responsible for upgrading the applications, databases and operating systems. The other project was assigned to move the applications from datacentre AB to datacentre CD as quick as possible. The third project was concerned about rationalizing the total application landscape in order to reduce the amount of applications and according interfaces. The first two project called LCM and Move were done simultaneously and the rationalization project will be done after the two project (LCM and Move) are finished. The simple reason for doing that is that rationalization takes an enormous amount of time, resources (from the business too) and money. That luxury we did not have!

Furthermore the project team decided, besides splitting up the project, to use highly specialized migration tooling that was capable to a discovery of all the applications and their dependencies to all other applications and at the same time to do a deep and detailed discovery of dependencies between applications and underlying ICT infrastructure.

Another key decision was that we would use the Strechted Vlan technology as a vehicle to move applications without changing the IP. This was a very big concern! Due to this decision we also decided to virtualize the applications as much as possible. By doing so we could use the VMotion technique to move applications quickly over dedicated DWDM (fibre optic lines) over more than 100 Km’s without any risk. Applications on very old systems that we couldn’t virtualize was handled by a dedicated team and these applications were moved manually. In order to the manually execution we designed a detailed run book where all details were discussed,documented and planned.

Besides discovering the applications and dependencies we also decided to use a tool which would discover all the data streams on the datacentre level and application level. The logic behind this was that we wouldn’t want to miss out anything. By analysing the data streams we were able to detect all kind of traffic like remote connections, systems management connections and so on.

Concerning the organization of the project we made two compelling choices. First we got ride of this twaddle about “customer and supplier” paradigm.  The success factor here was to jointly work together as one team with only ONE result. Secondly, in order to do the migration quickly, we asked security to give us a temporary dispensation based on the risks we identified but could not be mitigated within the time-frame set by the project.

Steps to take in a nutshell

  1. Initial stage – Inventory and dependency discovery: Use and extended automated inventory solution which is certified and proven dedicated application migration tool to execute an overall inventory and dependency checker and do the move of the applications (based on virtualization) based on the discovered dependencies.
  2. Design main level migration:
    1. Less time and limited budget:
      1. Design and build a simple stretched Vlan on layer two and avoid spanning tree,
      2. Renew and build  a temporary storage solution to handle large portions of data transfer. This temporary solution must fit and accommodate the stretched Vlan. Use fast DWDM-lines and virtual switches like the Nexus 7000 and 5000..
      3. Build new to-be infrastructure
        1. consisting of (certified) hardware with several interfaces
        2. virtual clusters (ESX on HP-blades)  and virtual networks (NSX),
        3. realize the required connectivity (AD, NTP, DNS et..) and generic services (monitoring and backup),
      4. Determine and take care of biggest security risks with Security and request a permisson like zoning, administration rights, remote access 3rd parties, et..
      5. virtualize applications and create detailed run books ,
      6. move applications to the to-be environment by using certified tools for migration, and to a partial relocation of layer 3 shared application infrastructure devices,
      7. Do additional scanning of the infrastructure and take care of the “left-overs” which  eventually can cause a major problem if not detected.
      8. Do an handover to support and temporary adjust/lower the KPI’s
      9. Take care of the lose ends in the after care phase and take care of project closure by executing the administration of the project and CMDB.
    2. Sufficient time and budget:
      1. Upgrade as much as possible the application infrastructure and according IT infrastructure
    3. Unlimited time / on-going process and big budget:
      1. Rationalize the application infrastructure
      2. Upgrade as much as possible the application infrastructure and according IT infrastructure
      3. Standardize environment
      4. Improve IT-processes, certainly CMDB and change management, design and documentation as well as document management

Many other issues played a role within this project but these issues doesn’t contribute to key message of this article. Important is to evaluate the decisions / choices we have made when you want to migrate on a large scale all kind of applications.

Read also about: Application migrations to the Cloud

Herman Rensink, Infrastructure architect.

herman-LI

Advertisements

2 thoughts on “Key decisions of a complex application migration

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s