Object migration lets you copy resources from one portal to another. 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.
You can copy resources from one portal to another by creating migration packages, which 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.
Table 6-1 summarizes the features of object migration.
Table 6-1 Migration Features
Migration Feature
Description
Portal objects that can be included in the package
All objects
Collaboration and Publisher information
Can migrate Collaboration or Publisher information
Requests and approval
Users with at least Edit access to objects can request migration, but only members of the portal administrators group can approve objects for migration.
An administrator selects approved objects to add to a migration package, and can also add object to the package without making a migration request.
Users with the Access Utilities activity right can check the status of their migration requests.
Creating a migration package
Only users with access to the Access Utilities portal activity 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
Dependencies always maintained. Dependent objects can be included in a migration package, but do not need to be.
Unique universal identifiers (UUIDs) and their effect on subsequent importing migration packages
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.
Using Migration Packages
The Migration - Export utility in the portal lets you create migration packages. To import objects from a migration package, you use the Migration - Import utility.
There are several things you can do to make migration as easy and effective as possible:
Keep source and target portals as similar as possible to reduce the mapping required.
Create migration packages as soon as possible after approving objects. The object settings in a migration package are those present at package creation, not those present at object approval. Creating migration packages soon after approval minimizes the chance that object settings have changed since approval.
You can selectively import objects in a migration package, so if you want to import content crawlers and communities separately, you can import a package twice, and select different objects each time you import it.
Creating a Migration Package in the Portal
You can create a migration package that includes portal resources as well as Publisher and Collaboration information.
To create a migration package in the portal:
Click Administration.
In the Select Utility drop-down list, click Migration - Export.
Add portal resources, and if applicable, Publisher and Collaboration information, as described in the online help.
Click Finish. A status message is displayed as the migration package is being created. When the migration package is created, you can download it to your desktop.
Note: If you are also migrating Collaboration or Publisher objects, those will be written to a .zip file on the machine where Collaboration or Publisher is installed. You must move this file from this location to the target location.
Creating a Migration Package Using a Command Line Tool
To create a migration package that includes portal resources:
Log in to the host computer for the portal as the user who owns the portal installation.
Use the command ptmigration.bat (for Windows) or ./ptmigration.sh (for Unix) with the following parameters:
Required. The name and path of the migration package to be created
log file name
Required. The name and path of the log file to be created. The path to the log file must be different from that of the migration package.
-exportdependencies
Optional. Use this parameter to export any additional objects upon which the objects you are exporting depend.
Note:
You cannot export Collaboration or Publisher objects using the command line tool. To export those objects, use the Migration - Export utility in the portal's administrative UI. See Creating a Migration Package in the Portal.
Press Enter. All objects approved for migration are exported into the migration package. The migration utility updates the migration status in the source portal.
Importing Objects in the Portal
To import objects, including Publisher and Collaboration information, from a migration package:
Click Administration.
In the Select Utility drop-down list, click Migration - Import.
Upload the migration package, and select the objects you want to import, as described in the online help.
Resolve any unresolved dependencies as described in the online help.
Click Finish.
Importing Objects Using a Command Line Tool
To import portal resources from a migration package:
Copy the migration package to the target portal host computer.
Log in to the host computer for the portal as the user who owns the portal installation.
Use the command ptmigration.bat (for Windows) or ./ptmigration.sh (for Unix) with the following parameters:
Required. The name and path of the migration package to be created
log file name
Required. The name and path of the log file to be created. The path to the log file must be different from that of the migration package.
-noacl
Optional. Use this parameter if you do not want to import the Access Control Lists (security data) associated with the objects you are importing.
-overwriteremoteservers
Optional. Specifies that existing remote server objects should be overwritten by remote server objects in the migration package. The default is that existing remote servers are not overwritten.
-createnewobjectinstances
Optional. Use this parameter if you want to create new object instances instead of overwriting objects that may already exist on the importing portal.
Press Enter. All the objects in the migration package are imported. The imported objects are located in the same folders on the target portal as on the source portal. Objects with missing dependencies will be skipped and not imported. Check the migration log to see which ones were skipped.
Backing Up and Restoring the Portal
You can back up your system without taking it offline.
To back up your portal:
Back up your database according to your database vendor documentation and best practices.
Back up your search collection to another location or tape backup.
To restore your portal to a previously saved state:
Stop the Web service on all machines hosting the portal application.
Stop the BEA ALI Automation Service on all Automation Services.
Stop the BEA ALI Search service.
If you need to rebuild your portal database, use your database software to restore from a previously saved database.
Replace your search collection with backups as close as possible to the time of the database backup you are using.
Your database backup might not exactly match your search collection backup, so the restored database and search collection will be out of sync. To correct this, rebuild the search collection from scratch.
To rebuild the search collection:
Reinstall the Search Service and select Overwrite the existing search index. For details, refer to the Installation and Upgrade Guide for AquaLogic Interaction.
Configure the Search Service to run an update:
Click Administration.
From the Select Utility drop-down list, choose Search Service Manager.
Under Search Repair Settings, change Next Repair Date to a time in the past.
Click Administration.
Click the Intrinsic Operations folder.
Click a Search Update job and schedule it to run immediately.
