Overview of a migration project

A migration project for any live WebSphere Commerce site is an activity that must be carefully thought out. There are three main phases to the migration project – the planning phase, the practice phase, and the production migration phase. Each of these phases requires its own skills and resources. Allocating sufficient time for each activity is crucial to ensure that no key tasks are forgotten.

There are resources available to assist you with planning your migration project:

• IBM Software Services for Commerce

• IBM Business Partners: Contact IBM for information about IBM Business Partners who can complete a WebSphere Commerce migration, and are local to your geographic area.

Planning phase

In the planning phase, you take inventory of the current WebSphere Commerce assets, such as documentation, servers, software, databases, and custom code. It is crucial to know which customizations you have, and where your system integrates with external systems.

• Document your business requirements:

  • Determine whether the requirements dictate that you need to use a different WebSphere Commerce business model or edition.

  • Gather all documentation that you have available on the current site, including design documents, use cases, and test cases for the current implementation. If the documentation is not current, consider updating it, and ensuring you have access to the original development staff.

• Document your hardware requirementsTip: Migrating the production environment to new hardware is recommended, as the original environment can be used as a fallback environment. Using new hardware also minimizes site downtime because the following tasks can be performed:

  • The new environment can be set up in advance. For more information about setting up development environments, see Set up a WebSphere Commerce Developer environment. For more information about planning your production environment, see Planning the production environment.

  • Migrated customizations can be deployed and validated in advance.

  • If we are planning to add more hardware, we can use the new hardware for the new site, and then use the current hardware to add extra capacity or as extra testing environments. Adequate performance test systems are an important part of a high performance WebSphere Commerce site architecture.

• Know the skills that we are going to require for each stage of the migration, for example:

  • A project manager.

  • A solution architect who understands the site topology, integration points, and all technologies used.

  • A database administrator.

  • Developers who are experienced in the languages used for any customizations you performed.

• Ensure that the development environments and test environments are synchronized with the version of the code currently in production.

• Create a detailed schedule that includes users, passwords, tasks, owners, timing, check points, validation steps, and roll back plans.

  • Determine whether any training is required for our technical or business staff to use new technologies, programming languages, or related software.

Practice phase

The practice phase is divided into two or more parts, depending on your business.

Migrating the development environment

• Attempt to migrate a development environment early in the project to identify changes required to custom code.

• It is important to successfully migrate a development environment early to allow developers to write code on the new version of WebSphere Commerce.

Tip: Create a development environment, and then migrate the WebSphere Commerce site as-is. We can regression test the resulting site to see what works and what doesn't, and refine your project plan.

Migrating the test environment

• Perform end-to-end migration to learn what to expect during production migration.

• Reduces uncertainty and downtime during migration.

• Timing each migration activity on the test environment provides valuable input that we can use to refine your project schedule for the production migration phase.

• A test staging environment is a valuable asset in this phase to test rebuilding the staging environment from your test server.

Production migration phase

The version 9.0 migration offers a minimal downtime solution, so when you migrate your live environment to version 9.0, we can continue to serve traffic. Here is how it works. Most of the production migration takes place offline. In fact, the live database is the only tier from your production environment that gets migrated directly from one runtime environment to another. And that database migration can occur in parallel to serving traffic. For more information about the high-level migration steps, see High-level guideline for a switchover migration.

Related reference
Migration diagram
Creating a migration plan