Browse Prior Art Database

Midrange Unix Migration Process

IP.com Disclosure Number: IPCOM000029896D
Original Publication Date: 2004-Jul-16
Included in the Prior Art Database: 2004-Jul-16

Publishing Venue

IBM

Abstract

Problem: How do you scope, plan, schedule and deploy Software Currency, (commonly referred to contractually as "N-1") across a large number of disparate, legacy systems ? Solution: The Midrange Unix Migration Process (MUMP) attempts to solve several of the more common problems with strategic outsourced service delivery in a large Midrange account. The main advantage of this methodology is that it fuses two independent support views of the major objects in the migration. 1. the Developer's / Business Unit's focus - that is the application as a whole (as it supports the business functions). 2. the Systems Operation's focus - this is each individual server on which the application runs. The two views are fused in the methodology by having the migration analysed by application but scheduled via host. This wholistic view means that both sides (Developer/Business Unit and Operations) issues are recognised and solved rather that being in conflict. Features: * The process analyses the scheduling requirements of the migration from an application-centric point of view. This benefits for the Application Developer Teams. It then schedules each of the changes that are required by host. This benefits the Operations Teams. * Tools with embedded "intelligence" allow for varying experience levels. * The process has been designed with the expectation that the Operations and Developer Departments have differing abilities, procedures, motivations and goals. * The process takes into consideration the need to explore any Application (or host) to Application (or host) dependencies. This effectively means that the impacts of migration and/or exemptions are better understood to the community as a whole. * Although being initially designed for total infrastructure refresh, the process could be adapted for partial infrastructure refresh (not all S/W is replaced), new account transition (hosts are brought up to a standard where they may be effectively managed via IBM GSA), consolidation (host are relocated from disparate locations into a data centre) and rationalisation (applications being serviced by multiple low capacity hosts are relocated onto fewer, highter capacity hosts).