Services

Tackling technical risk in ISV application migrations – Part 1

Share this post:

Among the list of common migration worries that organizations face, technical risk is always near the top, and the potential technical challenges of a migration vary depending on the type of migration. In this post, I’ll cover the common concerns when migrating Independent Software Vendor (ISV) applications to a new platform.

Migrating ISV applications

Here are some important points to consider when discussing an ISV migration.

First, there are thousands of ISV applications in the marketplace today, and it’s not possible for any hardware vendor to provide migration assistance for all of them. The good news is that most ISVs have a service offering to help clients move to a new platform, and IBM can partner with these vendors if necessary.

Second, all ISVs certify their products to run on specific platforms, so from a technical point of view we’re not migrating the ISV’s source code from one platform to another. We’re installing the version of the ISV application that’s certified by the vendor to run on the target platform and then migrating the associated databases.

Finally, most ISVs have tools and processes for moving their applications to different platforms. It’s in their best interest to do this because very few organizations today will invest in a solution with no way to change platforms should something go awry with their current vendor. The client and the ISV will resolve any new licensing requirements that may arise as a result of the migration.

The ISV migration process is therefore pretty straightforward:

  • Install the application code on the target system (this is the version of the ISV code certified for the chosen target system)
  • Migrate the associated databases
  • Test
  • Go live

A few important notes

Let me offer two notes here:

  • Most ISVs provide ways for clients to customize their applications, and if these customizations are done as defined by the vendor, they can easily be moved as part of the migration. Seldom if ever does the ISV allow the client to change their source code.
  • When we migrate the associated databases, we usually do two mock migrations on the production instances prior to the final cutover on the new system. Each mock migration is thoroughly tested by the client. Test time is driven by the client and can take several weeks per instance depending on the client’s requirements. By the time the client is ready for the final cutover, its environment has been through extensive testing, and most, if not all, of the perceived worries and concerns have been resolved.

But what if something catastrophic or unexpected happens during the final cutover? Will you lose your valuable production data? The answer is no because you have the ability to stop the cutover process if you suspect a problem. Your source database has not been changed so we simply roll everything back, resolve the issue and reschedule the cutover for another weekend.

An example ISV migration method

SAP is a great example of an ISV that has a well-defined migration methodology that helps eliminate most of the risk and technical worries when migrating SAP applications from one platform to another. There are three key elements to the SAP process that help ensure a successful migration:

  • The migration team is staffed by SAP-certified OS/DB migration engineers.
  • The migration is done using standard SAP migration tools.
  • All production databases undergo several mock/test migrations prior to cutover (go-live) on the new system.

While all of the above sounds good, I’m sure you’re asking yourself, “What are some of the other things that can affect the successful outcome of an ISV migration?”

Click here for part 2 and a discussion on common ISV application migration issues and how IBM Systems Lab Services Migration Factory remediates them.

Add Comment
One Comment

Leave a Reply

Your email address will not be published.Required fields are marked *


Martin Carangelo

Great article Skip. I think its important for everyone to understand that the source and target systems have to be exact. This includes all the patches, and as you mention customizations, that are applied to the source. This is a step often forgotten but can increase migration time w lot.

More Workload & resource optimization Stories

How a strong cloud architecture primes you for hybrid cloud

Across the information technology world, cloud has become ubiquitous. Cloud computing has inspired many startups to adopt technology quickly and deliver services that would have taken months to develop and deliver in the traditional era. While companies ride that wave, many have come to the realization that not all workloads are cloud friendly. Data privacy, […]

Continue reading

Finding a trusted backup and disaster recovery solution

Organizations today face significant challenges in managing the cost, complexity and capabilities of their backup systems. They need simple backup and disaster recovery solutions that are optimized for their environments, help reduce costs and offer a quick return on investment. My team recently worked with a large insurance company in India that had just refreshed […]

Continue reading

Reap the benefits of optimized workload management software

How do you speed up time to market for electronics in an industry that’s already moving at a rapid-fire pace? One answer is better resource utilization through effective workload management solutions. Mentor Graphics, a US-based global leader in electronic design automation, has a mission to enable companies to deliver better electronic products more quickly and […]

Continue reading