Migration plans: Rehost, Replace, or Retire
November 5, 2014
Migration begins with an inventory. Application by application, an IT manager does triage on every program on their 3000. The goal is to come up with a disposition for each app. Some ccan be rehosted. Apps built with PowerHouse might be moved to other servers, for example. For other apps, they can be replaced. Ecometry sites could adopt the CommercialWare application, in some cases. Or in other instances, an in-house program suite can be replaced by a Commercial Off The Shelf app. Migration services company MB Foster likes to call those replacements COTS. The company has a Wednesday webinar scheduled on Nov. 19 to explore planning to replace COTS and more.
Foster calls the strategy the Three R's of Migration: Rehost, Replace, Retire. At 2 PM Eastern Time in a couple of weeks (register here), Birket Foster will lead a slide talk with time for questions about what to do if you're migrating away from any one of the above types of applications. The word Retire is already on the minds of MPE-savvy managers, since most of them are older than 50. It turns out that applications can find the end of a career even before their caretakers do.
It's not always this way. At the San Bernadino County schools, the apps to run the California district will have a retirement date from the 3000 that falls after the district's 3000 expert. Sometimes, though, a migration can become easier when older programs that have fallen into disuse are simply erased. There's no need to migrate such an app.
However, there's only one sure way to discover these retirees: inventory and analysis. MB Foster's summary for the Nov. 19 webinar breaks that triage process into inventory of app environments; rating the functionality vs. business suitability of each app; then organizing and prioritizing with a study of interfaces and grouping used that applies to each app. COTS carries a different set of requirements to study during migration planning, the company says, than in-house apps.
The first stage in the lifecycle is a requirements document. What are the workflows being supported? Was the application built or bought, and what roles were considered as the project to charter the application began? If the application is built in house, then technical documentation for the app's design and delivery will be required. If the application is COTS software, then the requirements documentation changes, to include the software selection process and a Fit-Gap analysis.
Every application spends time crossing through three environments: Development, Test, and Operations. Migrating anything means that IT management must consider how to move away from Development elements such an IDE, or source control software, change control tools, scripting languages, and compilers.
Foster says in its summary for the webinar that making a transition away from an app's Test environment means analyzing the test tools, methodologies, test scripts, plus documentation for the app's unit test, integration test, and UAT (User Acceptance Test).
The inventory for analysis of an Operations environment studies "scripts for operating daily, weekly, monthly and other periodic functions," as well as "the toolkit for monitoring the production environment (unique or shared), the scheduler, and other production environment tools."
The analysis will allow the 3 R's of migration to be applied – Rehost, Replace or Retire. Once the application portfolio is divided into these categories, it is time to organize and prioritize the applications. Each application may be standalone or grouped – and the triage process will need to note any internal or external interfaces that will be impacted.
Foster says the webinar will examine and teach about those processes. It might be a way to bring something closer to retirement: an aging 3000, or even old business practices for IT.