High-availability systems

Many solutions, especially those that use Web Content Manager, require constant access to either authoring environments where content is constantly updated or created, or delivery environments that render websites that cannot be taken off-line. In these cases, migration cannot be performed directly on the local server, but must instead be performed on a remote server. The steps required to migrate system to a remote server will differ depending on what version you are migrating from.

Migrate a v6.0.1.x high-availability system

When migrating a v6.0.1.x you will always be migrating to a new environment, so there is little difference between high and low availability systems. The basic process of migration is the same for both types of systems.

During the migration process, users will still be creating web content on the original v6.0.1.x system. Once the V7.0 system is fully migrated and tested, you can quickly update web content by performing a Update data after migration. This will update the content of V.7.0 data repository to match the latest data on v6.0.1.x system.

Migrate a V6.1.x high-availability system

When migrating a V6.1.x you are essentially updating current system. This migration process is not suitable for high-availability systems because system will not be available to users during the migration process. In this case, you need to do one of the following:
Take a clustered server off-line

In this scenario you have a set of clustered servers. You take one of the servers out of the cluster and perform the migration on this server. Your users continue to use the original system until the new system is ready to be used.

Make a clone of one of V6.1.x servers

In this scenario, you create a copy of V6.1.x and perform the migration on the copy. Your users continue to use the original system until the new system is ready to be used.
Copy configuration settings:
You use xmlaccess.sh to copy configuration settings from V6.1.x system.

Cloning web content:
You can clone web content data repository to the remote system that will be migrated: Cloning a web content repository wp7

During the migration process, users will still be creating web content on the original V6.1.x system. Once the V7.0 system is fully migrated and tested, you can quickly update web content by performing a Update data after migration. This will update the content of V.7.0 data repository to match the latest data on V6.1.x system.

Parent

Migrating
Understand migration
Supported migration paths
Plan for migration
Migrate v6.0.1.x
Migrate V6.1.x on a V6.1 application server
Migrate V6.1.x on a V7 application server

Related tasks

Deploy new functionality in a migrated portal
Update data after migration

 

+

Search Tips   |   Advanced Search