Migrating Content Delivery Server

C H A P T E R 1

This chapter walks you through the steps involved in transitioning from the Content Delivery Server, version 5.0 to the Content Delivery Server, version 5.1. It also calls out specific steps for migrating from version 5.0 PU1 to version 5.1 where the migration procedure differs from the 5.0 to 5.1 migration.

This chapter covers:

Migration Procedure

Preliminary Migration Steps

Migrating Content Delivery Server

Testing the Migration

Note - This document does not cover the use of the Subscriber API. If you intend to use the User Interface and Subscriber Portal API, you must perform a separate migration process from what is discussed in this document to address those areas.

Migration Procedure

The migration procedure consists of the following phases:

1. Performing preliminary migration steps, for example, integration of properties and migrating branding and localization information

2. Migrating the Catalog Manager

3. Migrating the Vending Managers

4. Starting the new version of the Catalog Manager and Vending Managers

5. Updating the Catalog Manager’s Vending Manager Server Accounts information.

After starting the new version of the Catalog Manager, you might want to perform some testing to ensure that the migration is successful. See Testing the Migration for more information.

It is not necessary to shut down the entire Content Delivery Server system during migration. You can reduce the total down time of the system by following the outlined procedure. While you are migrating the Catalog Manager database, the Catalog Manager is put into READ ONLY mode and access to the Developer Portal and the Catalog Manager is restricted.

Vending Managers can continue to run, providing service to customers. After the Catalog Manager migration is complete, Vending Managers can be migrated in parallel or one at a time. Use the strategy that is most efficient for your needs.

Note - Specific details of migrating Content Delivery Server vary from user to user. Be aware that some steps might not apply to your particular situation. Also, the time required to complete each phase is dependent on the deployment configuration and the number and type of components involved.

For detailed procedures on migrating Content Delivery Server, see Chapter 4.

For the rest of this chapter, the term “old version” refers to Content Delivery Server, version 5.0 (or 5.0 PU1 as applicable). The term “new version” refers to Content Delivery Server, version 5.1. Where the procedure specifically addresses 5.0 PU1, that version is called out explicitly.

Preliminary Migration Steps

Prior to migrating the Catalog Manager database, you must perform these high-level preliminary migration steps:

1. Apply back-up safety procedures.

For example, back up the database for the old version of Content Delivery Server and copy the old version of Content Delivery Server’s installation directory to a backup directory).

2. Install the new version of Content Delivery Server with a default database following the instructions in the Sun Java System Content Delivery Server Installation Guide.

The database initialization for the migration procedure is different from the one used for the default deployment. The cdsi db init command creates empty database and tables. It then populates some of the database tables with default data. The migration process requires a clean database, which has absolutely no table data and has no foreign key constraints imposed between tables. To accomplish this requirement, you need to create the database using the following two commands:

$cdsi db users
$cdsi db schemas_noc [-conf {dbconf}] [-cs] [-vs {vending}]

The first command creates users on the database server. The second command creates all the tables without creating any intertable constraints.

Note - The cdsi db users command completely erases any information associated with the database users specified in the DBConf.xml file, so if you have already created an empty database with cdsi db init, start over by running cdsi db users.

Note - The cdsi db schemas_noc command is not documented by cdsi help.

3. Configure your new deployment to connect to your basic integration components.

For instance, such components can be the Wireless Access Protocol (WAP) and Push Proxy Gateway (PPG), Lightweight Directory Access Protocol (LDAP), Short Message Service Center (SMSC), Senders and Receivers, and Notification and Email Server.

This integration migration step consists of modifying custom adapters to use them with the latest version of Content Delivery Server. Typically, the following adapters need to be migrated:

Billing Manager adapter

Postpaid adapter

Subscriber adapter

A default implementation instance is provided for each adapter.

Configure the properties migration file, $CDS_HOME/cfg/migration/props_migration_5.0_5.1.xml, to migrate properties and existing localization data from the old version to the new version of Content Delivery Server. You must migrate any new localization information.

If you are migrating from version 5.0 PU1, configure the properties migration file, $CDS_HOME/cfg/migration/props_migration_5.0PU1_5.1.xml instead.

4. Run the cdspm migrateprops -f props_filename command to migrate the configured properties.

For detailed information on configuring and running the properties migration file, see Chapter 2. For information on directory and file structure changes, see Chapter 3.

5. Migrate all branding information to your new Content Delivery Server deployments.

You must manually migrate all branding information so that the branding information in version 5.0 (or 5.0PU1) of Content Delivery Server is preserved. Run and test branding in a separate thread prior to live migration so can you see how branding is deployed in version 5.1 of Content Delivery Server. Branding migration can be time consuming depending on the complexity of the customization and the number of sites to be branded.

Branding migration can include, but is not limited to, the following operations:

Migration of images

Migration of pages created with JavaServer Pages (JSP) technology

Migration of the localization and dynamic banners

Migration of the style sheet

Creation of a devices style sheet

Migration of directories and files

Migration of operator-specific customizations

Note - Remember to add any new information that you need that is not contained in the old version of Content Delivery Server, such as libraries. You must also reset values for default devices, default Vending plans, Developer plans, and other such administrative information.

This step assumes that you are familiar with branding and customizing Content Delivery Server. See the Sun Java System Content Delivery Server Branding Guide and Sun Java System Content Delivery Server Customization Guide for details.

6. Test the core Content Delivery Server functions, including old and new services, all branded portals, and your basic integration components.

See Testing the Migration for more information.

7. Deploy any custom integration adapters.

This step assumes that any custom adapters are compliant with Content Delivery Server or have been extended to work with Content Delivery Server prior to the migration phase.

8. Test the fully integrated Content Delivery Server deployment.

Note that the server must be fully configured to your specification, which includes configuring the workflows before the migration is executed. See the Sun Java System Content Delivery Server Installation Guide for information on how to edit the SubmissionVerifiedWorkflows.xmlfile to meet your deployment needs.

Try performing a preliminary migration test in a development or staging environment to determine the approximate length of time it takes to migrate your configuration of Content Delivery Server.

Migrating Content Delivery Server

Create a new database even if the same database server is used as the schema for the new version of Content Delivery Server could differ from the schema used in the old version.

Note - The Vending Manager can continue to run and service customers during this phase of the migration.

During the migration of the Catalog Manager database, the following requirements must be met:

The Catalog Manager is run in READ ONLY mode until the end of the migration process.

No modifications can be made to content in the Catalog Manager database. Any modification corrupts data migration and creates a discrepancy between the old and new versions of Content Delivery Server database.

No new content can be submitted to the Catalog Manager at this time.

Note though, that for Vending Managers, content can be freely stocked and unstocked.

Schedule the beginning of the migration in accordance with their affiliates to set expectations and to determine when to stop the Catalog Manager.

This phase consists of the following high-level steps:

1. Stop all managers and servers that are running the new version of Content Delivery Server deployed during the preliminary phase.

2. Restrict access to the Catalog Manager database by putting the Catalog Manager into READ ONLY mode.

READ ONLY means that no modifications can be made to the Catalog Manager database, that is, developers cannot submit any content and administrators cannot make any modifications. The Catalog Manager and the Developer Portal are considered frozen. Do not make any changes that would affect the database. The following actions can help you to prevent changing the database:

Disable the developer accounts.

Disable all Catalog Manager administrator accounts except for one.

Restart the Catalog Manager and the Developer Portal, if needed, to drop all existing users that are logged in.

3. Migrate the Catalog Manager database to the new version of Content Delivery Server.

For detailed steps on migrating the database, see Chapter 4.

4. (Optional) Run the migration verification script.

Verify the database migration after each migration step. For information on running the script, see Verifying Migration Completion in Chapter 4.

5. Stop the Catalog Manager and the Vending Manager that are running on the old version of Content Delivery Server.

a. If the Catalog Manager and the Vending Manager are on the same server, shut down both managers.

b. If the Catalog Manager and the Vending Manager are on different servers, shut down the Catalog Manager.

The Vending Managers can continue to run but vending services (for example, Event, Messaging, Postpaid, and Monitoring) must be stopped.

6. Migrate the Vending Manager database to the new version of Content Delivery Server.

During the migration of the Vending Manager, no activity can take place on the Vending Manager or its associated subscriber portals.

7. (Optional) Run the migration verification steps.

8. Start the managers in the new version of Content Delivery Server.

a. If the Catalog Manager and the Vending Manager are on the same server, start both managers in the new version of Content Delivery Server.

b. If the Catalog Manager and the Vending Manager are on different servers, start the Vending Manager only after the Catalog Manager is running in the new version of Content Delivery Server.

9. Shut down any other Vending Managers that are still running on the old version of Content Delivery Server and stop all their services.

10. Migrate any other Vending Manager databases to the new version of Content Delivery Server.

11. (Optional) Run the migration tests.

12. (Optional) Set specific content types to be read only.

During the migration process, some content types might not have an attribute that allows the content type to be edited or to be read only. To ensure that certain content types are not editable, follow these steps after the migration and migration verification processes have completed for all catalog and vending managers:

a. Make sure all deployments are stopped.

b. Run the following SQL command:

update content_type set editable=0 where name is (‘bundle’, ‘midlet’, ‘text’, ‘iappli’, ‘streaming_video’, ‘streaming_audio’);

The SQL command must be run against the catalog database (_PS_APP suffix) and all respective vending databases (_VS_APP suffix).

After deployment of the new version of the Content Delivery Server, the content types specified in the SQL command are treated as read only.

13. Start the other Vending Managers in the new version of Content Delivery Server.

You can now start the Vending Manager services. You can also stop any service outage counter you might have running. You are now running version 5.1 of Content Delivery Server. Do not attempt to reuse the version 5.0 (or 5.0 PU1) server because any changes made in that database are not reflected in the new database.

Testing the Migration

To ensure that the migration of Content Delivery Server was successful, a thorough testing of the following migration areas are essential:

Database and property configurations

Branding

Individual server and service migration

Integration

Finally, test a fully integrated and branded version of Content Delivery Server after the migration of each of the listed areas is completed.

The migration testing includes, but is not restricted to the following areas:

Production customer data imports (private network and reduced access)

Branding and the device user interface migration

Database and properties migration scripts

Integration migration testing for batch, real-time billing, and user profile

Migration test plans development (progressive test cases)

For information on migration verification, see Verifying Migration Completion in Chapter 4.