You can copy objects from one portal to another using migration packages. You might want to do this for several reasons. You might have multiple portals to handle a global deployment or you might want to create multiple portals to separate development, testing, and production.
Migration packages can be used to:
Export objects created in a development portal and import them to your production portal when they have been properly tested.
Import portal objects in order to install new features on your portal. For example, you might want to install a portlet suite and register those portlets in your portal.
To create a migration package, use the Migration - Export utility. To import objects from a migration package, use the Migration - Import utility.
For information on the command line version of the migration utility, refer to the Administrator Guide for Oracle WebCenter Interaction (available on the Oracle Technology Network at http://www.oracle.com/technology/documentation/bea.html).
Migration has the following features:
|
Feature |
Description |
|
Objects that can be included in the package |
All objects |
|
Collaboration and Publisher content |
If you migrate a community that includes Collaboration or Publisher content, you can also migrate this associated content. For example, if you migrate a community that includes the Community Discussion Messages portlet, you can migrate the projects included in the portlet and their associated content. |
|
Requests and approval |
Any user with at least Edit access to objects in the administrative object directory can request migration of those objects, but only users that belong to the Administrators group can approve the requests. The administrator then selects approved objects to add to a migration package. |
|
Creating a migration package |
Only administrators can create a migration package. An administrator can add objects that do not have migration requests to a migration package (bypassing the request and approval process). |
|
Object dependencies |
Dependent objects can be included in a migration package, but do not need to be. |
|
UUIDs (Unique Universal Identifiers) and their effect on subsequent imports/migrations |
By default UUIDs are maintained, so that subsequent migrations overwrite previously migrated objects. However, if you do not want to overwrite previously migrated objects, you have the option of creating a new instance of the same object, with a new UUID. |
Notes on migration:
Users that are members of the Administrators group can also approve an object for migration (without a migration request) from the Migration History and Status page of the object editor or the Save Object dialog box. The object is automatically added to the list of objects approved for migration.
New remote servers can be migrated, but subsequent edits to remote servers are migrated only if you select Overwrite remote servers during import. Because remote server settings are generally specific to a particular portal, the default setting is not to overwrite remote server objects.
The object settings in a migration package are the settings present at the creation of the migration package, not the settings present when the object was approved.