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.
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.