newsroom

I recently wrote about the top five application and system migration worries organizations face when a change in technology platforms is required. In this post, I want to set out a basic framework for a typical migration process before taking a deeper dive into each of the top five application and system migration worries.

Understanding migration worries from each stakeholder’s perspective

In any migration, there are stakeholders representing different constituencies within an organization, all with their own concerns, worries and perceptions. They typically fall into one of the three categories:

• Stakeholders focused on the technology. These are usually IT folks, system administrators, database administrators, storage, network and basic infrastructure resources who are very close to the basic technology and may be biased toward one technology over another, especially if they’ve been using it for 20-plus years.
• Stakeholders focused on running the business. These are line of business managers, application developers and people responsible for getting a product or service into the market. They may or may not care what the underlying technology is so long as it is reliable and cost-effective.
• Stakeholders focused on managing the company. These are the executives and senior managers who probably don’t care about the specific technology choices as long as they are comfortable that these decisions will enable them to grow the business and maintain a competitive advantage in their markets.

The technology stakeholders are likely to have architecture concerns and worry about things like platform incompatibilities, endian issues, compilers and data structures. Line of business stakeholders worry about the impact on the business and taking any type of outage. The senior managers worry about whether this is the right strategic investment for the company and if it is “bleeding edge” technology or one with a proven track record.

These are three very different audiences, and anyone who is advising them on a migration needs to be sure to understand their concerns and communicate to them in a language that eliminates objections for selecting the right technology for their needs.

How personas help us identify and address common worries

One of the techniques in design thinking, called personas, helps us focus on the concerns and worries for each of these groups. Personas are fictional representations of stakeholders. In IBM Systems Lab Services Migration Factory, our workshop and assessment process involves creating realistic personas for each of the stakeholders we’re working with. This is essential in helping us understand their concerns, communicate the correct messages to them and in turn, keep the workshop and assessment focused on the goals, motivations and desires of the client.

As we explore the top worries a client has about migration, this technique is key to ensuring we address all their concerns correctly.

The four basic components of a migration

Breaking a migration down into its key components is one way to help all of the stakeholders understand what to expect. This helps them see what is involved and how IBM mitigates risk within each component of a migration. It can also help them understand how they might approach the project, whether a waved approach over time or migrating everything now.

There are four basic components we focus on:

• Infrastructure. This includes print and file servers, firewalls, security software and middleware products like IBM MQSeries. Web software like IBM WebSphere and Oracle WebLogic Server fall into this category. (IBM Migration Factory services do not include setup and installation of the target hardware, storage or network. This is usually done by IBM and/or an IBM Business Partner or third-party systems integrator. When we arrive to do the migration, we assume the target platform is installed and ready.)
• Databases. Oracle, IBM DB2, Sybase, IBM Informix and Microsoft SQL Server are the typical products we see in this category. These are usually low-risk entry points when considering a migration.
• ISV (third-party) applications. SAP, Oracle eBusiness Suite, Siebel and HANA are examples of products in this category. These are also usually low-risk migrations because most of these vendors certify their products to run on multiple environments.
• Custom code. C/C++, JAVA, COBOL and different scripting languages have been used to create the thousands of applications that companies use to run their mission-critical applications every day. These can have more risk than the other components because they may take advantage of unique system capabilities on the source system that may not be available on the target.

Some migrations may only involve databases, some an ISV application and its associated databases, and others, all four components.

In my next blog post, I’ll talk about how we use this framework to address migration worry number 1, technical risk. Please stay tuned.

The post Four basic components of a migration and why they matter appeared first on IBM Systems Blog: In the Making.