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:

Planning phase

In the planning phase, you take inventory of your current WebSphere Commerce assets, such as documentation, servers, software, instances, 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 requirements
    Tip: 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 installed and configured in advance.
    • Migrated customizations can be deployed and validated in advance.
    • If you are planning to add more hardware, you 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 you 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 that are used for any customizations you performed.
  • Ensure that your 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 your 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 that are required to your 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 your WebSphere Commerce site as-is. You 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 you can use to refine your project schedule for the production migration phase.
  • A test staging server is a valuable asset in this phase to test rebuilding the staging server from your test server.

Production migration phase

In previous versions, migrating your live production environment took place during a planned outage; you could not serve traffic during this time. Now, when you migrate your live environment from version 7.0 to version 8.0, you can continue to serve traffic. The version 8.0 migration offers a minimal downtime solution. 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.