Modern data platforms

Tackling technical risk in ISV application migrations – Part 2

Share this post:

We’ve identified “technical risk” as one of the most common migration worries for many organizations. Of course, the potential technical challenges of a migration vary depending on the type of migration. In my previous post, I introduced some important considerations when migrating Independent Software Vendor (ISV) applications to a new platform. Let’s continue that discussion with a look at the common issues that can affect the successful outcome of an ISV application migration, along with how we in IBM Systems Lab Services Migration Factory usually remediate them.

top questions for ISV application migrations, ISV Migration

The ISV application isn’t certified for the target platform

Only an ISV can certify its solutions for a specific platform. If you choose a platform that’s not certified, there are a few options available:

  • The ISV can choose to support the new target and migrate its source code to the new platform.
  • It can choose to allow the client and/or another third party to do the migration on its behalf and provide ongoing support.
  • It can choose to not support that platform.

IBM has migrated ISV code to our platforms on behalf of many ISV vendors, and we’ve helped clients find alternative solutions when the ISV has chosen to not support the new platform.

Application currency verification

Many clients run ISV applications that aren’t the most current version available from the vendor. That’s okay if the version you’re running is still supported by the vendor and certified for the operating system version running on the target platform. If it’s no longer supported, that can be an issue.

There are also clients who run ISV software that’s out of date and not supported. Upgrading to the latest version so the migration can be done can be a lengthy and costly process, but one that needs to be done if the client wants to move to a new technology platform. Neither IBM nor the ISV will migrate an out of date and unsupported version of the application to a new platform and guarantee it will work.

Application currency in a multi-vendor ISV stack

Many clients rely on multiple ISV products to round out their solution portfolios. A lot of these products are stand-alone and need only be certified for and supported on the target platform. Others may not. They may need to interact with other ISV products in the solution stack. So, in addition to being certified and supported on the target platform, they may need to have a specific version certified to run with other ISV products (for example, application A must be at version 2.xx to be certified for the target platform as well as interact with application B which must be at version 2.xx.3). The good news is that application currency checks and version verification is a fundamental part of IBM Systems Lab Services Migration Factory’s assessment process.

One final comment. In Migration Factory, we’ve been asked many times if we could migrate JD Edwards or PeopleSoft, or Oracle EBusiness Suite to SAP, and the simple answer is no. These are different applications with different data models and schemas. That said, if a client wants to undertake a project like this, there are ways to utilize the data from the older systems, but that’s not a traditional ISV migration and is a subject for a blog post of its own.

Hopefully this information eases your concerns about migrating ISV applications. Just remember that we’re not migrating the ISV’s source code. We are installing a version of its source code that is certified for the target platform.

IBM Systems Lab Services Migration Factory is always here to help you. We’re an experienced team of migration consultants with proven expertise to help you reduce the costs and risks when moving your applications and databases to IBM platforms.

Contact us today for a consultation.

More Modern data platforms stories

Top IBM Power Systems myths: “IBM AIX is dead and Unix isn’t relevant in today’s market” (part 2)

AI, IBM Systems Lab Services, Power Systems

In part 1 of this series, we started to look at the myth that IBM AIX and Unix are no longer relevant. We talked about the Unix wars that began in the 1980s and how the market has evolved since then. Now, let’s consider the evolution of AIX in the past few decades and the more

Top IBM Power Systems myths: “IBM AIX is dead and Unix isn’t relevant in today’s market” (part 1)

IBM Systems Lab Services, Power servers, Power Systems

Given the focus on cloud, Linux, AI, blockchain and other headline-grabbing topics today — plus IBM’s recent acquisition of Red Hat — it’s important to dispel the myth that IBM AIX and Unix are no longer relevant. When a technology isn’t front-page news every day, especially if that technology is older, the tech media circuit more

Building leadership skills to ensure your IT project’s success

Academic initiatives, IBM Systems Lab Services, Services

IBM Systems Technical University (TechU), as the name implies, offers a multitude of technical learning paths and sessions. No surprise there. However, you might be surprised to learn that many TechU events also offer an IT Leadership and Professional Development track with leadership sessions covering topics like governance, experience-based design and consultative selling. So, why more