Upgrade Preparation and Planning Guide

Overview

A well-strategized migration approach can make upgrade an efficient journey. This guide can help you form the general foundation for a detailed project plan.

Migration Approach and Phases

Timelines vary depending on the complexity and depth of the existing platform.

• Prerequisites
• Preparation for migration
• Cutover plan preparation
• Development of target environment
• Migration of QA: code migration, asset migration, data migration
• Migration of preprod
• Code merge
• System integration testing support
• UAT support
• Production rollout planning and go live
• Post go live support

The Delivery approach has 3 major successive phases: Preparation and Strategy, Migration, and Test and Rollout. Each phase is broken down into milestones.

Assessing Your Project

Assessment of middleware requires the following:

• Understanding services deployed and features built inside the middleware.
• External constructs of middleware, including the number of interfaces and end point applications.
• Internal constructs of middleware, including configurations, rules, transformation logic, flows, pattern usage, and custom code.
• Supporting information such as resource profiles in the current landscape, SLAs, quality management, governance, and non- functional requirements.
• Whether external clients connect to your applications. If so, typically host name and port numbers should remain the same, which requires planning.
• Understanding the complete landscape (number of environments, RDBMS, active developments, dependencies, and so on).
• Assets created using same framework/technology can be easily migrated/ deployed to the IBM webMethods platform, but some assets may require recreation to align with the IBM webMethods platform.

Assessment of the migration project itself requires the following:

• Decisions around project timelines such as when to migrate, migration time frame, timelines for testing, and support from IBM.
• Decisions around project cost and effort.
• Maximum permissible downtime for your product environment.
• Cutover period that is possible for your product environment on migration day.

The following tables list a typical upgrade assessment questionnaire that you can use:

Preparing for Migration

Read IBM-provided instructions around upgrade in their entirety. You can find the following sources of information in the Complete Installation and Upgrade Information for IBM webMethods Products help:

1. Read Upgrading IBM webMethods Products in its entirety so you are familiar with all tasks you need to perform.
2. Read the product release notes. The release notes provide information on new functionality. Read the information for every release from your old product release + 1 up to and including the new product release.

3. Read the product readmes for your old release+1 through the new release. For example, if your old product release is 9.9, read the readme information for product releases 9.10 through 10.7. Also read the readme for the same releases of IBM webMethods Infrastructure. Product readmes contain this information:

   • Critical information and known and resolved issues for your products.
   • Changes to product behavior, services, parameters, properties, and APIs. Such changes can include additions, changes, deprecations, and removals. This information is especially important because you might need to modify product files or assets after migration to accommodate product changes.
4. Check System Requirements for IBM webMethods Products . If the RDBMS version you are using is not supported by your new products, you will need to upgrade to a supported RDBMS version.
5. As you progress through the upgrade, apply newly released fixes for your products. Read the fix readmes to become aware of the issues they resolve and any changes in behavior.

We also recommend the following preparation steps:

• Set up operating guidelines that cover normal project management requirements across all affected groups in your organization.
• Define an approach to source control and set up release management tools and procedures that support the migration of data into target environments.
• Account for externals to the source webMethods environment you want to upgrade, such as clients that communicate with your webMethods products and that might need endpoint URL, host name, or IP address updates.
• As part of upgrading, take a baseline of the old environment and use that baseline to perform the upgrade procedure. IBM recommends a code freeze while you are migrating the baseline to the new environment.
• Many upgrade issues are caused by forgotten environmental settings. Plan, document, and test these thoroughly.
• For complex projects that require extensive system testing, extended code freeze might not be possible. In this case, define a change management strategy to track code changes that occur in the old environment. After testing is complete on the baseline, this will enable you to merge the code changes into the baseline and re-test the new baseline.
• Look for relatively simple yet meaningful interfaces that can help gain comfort with the new platform. If working with short deadlines, consider de-prioritizing interfaces that are less critical or those that can be mitigated by manual processes.
• If you need help creating your planning approach, contact IBM professional services.

Safely Migrating Your Environments

The most important question is the number of environments you have. It is quite common to have a development, test, and production environment. The first step could be to migrate your development environment, and to note the steps you are taking in the form of a checklist. As you go along, perform basic sanity checks and to make sure everything looks perfect.

When you think that you have documented that procedure, run through the procedure in your test environment as if you are doing the migration in your production environment. Perform detailed testing to make sure that everything works fine in your new environment. If you encounter issues, adjust your documented procedure if necessary. If you feel that the issue will have a big impact, you can choose to go back and rerun the tests in your test environment and then update the procedure and make sure that it will run smoothly when you apply it to your production environment.

Documenting the procedure will also help you determine how long will it take to perform the actual migration so you can plan for the downtime window. Most organizations have a maintenance window during which to migrate, optimally a weekend, but sometimes only overnight (6-8 hours). If you have less time than that, you will need more careful planning and preparation, particularly when you switch from one environment to another.

If you have a larger landscape, it might become impractical to migrate all servers within that landscape within a single maintenance window. In this case you can use phased migration. In phase migration, you try to migrate one set of servers that comprises one landscape, prepare the checklist of findings, and apply the same procedure to all other sets of servers one by one.

In summary:

1. Create a checklist that lists assets, known issues, and performance metrics in the old environment.
2. Migrate the development environment, document the steps that you perform in form of a checklist, and perform basic testing.
3. Test documented migration procedures on test environment and adjust the checklist as necessary.
4. Finally perform the migration procedure on the production environment.

Testing

The most vital and most time-consuming task of the migration process is the testing. IBM strongly recommends that you upgrade in a controlled test environment and test that environment for proper operation before promoting to your production environment. Testing can include the following tasks:

• Provision new environments to support the upgrade. Environments in which you conduct testing should mirror the production environment.
• Obtain test and performance data from the source environment and establish baseline results.
• Many upgrade issues are caused by forgotten environmental settings. Plan, document, and test these thoroughly.
• Identify test tools for unit, functional, and non-functional regression testing, and for performance and security testing.
• Define acceptance and sign off criteria.
• Automate a core set of regression tests for the upgrade. IBM recommends focusing your tests most heavily on product areas that have undergone the most change. The product readmes and release notes provide all product change information.
• If upgrading to new machines, make sure connections and firewalls are open to back-end systems before starting any system testing.
• Use an issue management system to track defects and issues.
• If code freeze of the old environment during test is not possible, merge code changes from the old environment into the baseline and re-test the new baseline.
• Make sure the migrated environment is correctly configured and there are no configuration issues.
• Perform unit testing.
• Perform functional testing.
• Perform user acceptance testing.
• Perform E2E testing and make sure there are no integration problems.
• Perform security and performance testing and make sure the performance test results match or exceed older metrics.

If you need help creating your testing approach, see the Upgrade Testing Guidelines in this webhelp or contact IBM Professional Services.

The following table lists some examples of very basic testing tasks. Prepare a list of all the testing activities.

Work Breakdown

A work breakdown with the major phases of the webMethods upgrade: Strategy, Blueprint, Realization, Rollout, Monitoring and Optimizing. Each phase is broken down into smaller tasks that contribute to the completion of the upgrade.