Tables to exclude when migrating the database, in file
exclude_tables
. 
Files to exclude when migrating the configuration files, in file
exclude_files
.
A mapping file that describes the corresponding values between source and target systems (using the "
-mapping
" option)

Gateway configuration files
(for example, node
.properties
): Add the name of the file to exclude; no path is required.
OS files
(for example, any files in
backup_manifest
): Add the entire file name and path of the actual file; for example, to exclude the file
/etc/hosts
from being copied from the backup image onto the host, add
/etc/hosts
as a new line in
exclude_files
.
Database files
(for example.,
my.cnf
): Same as "OS files" above.

Both the source and target Gateways are configured and operational. 
A backup image that has these components present: Gateway Database ("-maindb") and Gateway configuration files ("-config"). For more information, see Back?Up Gateways.
MySQL is installed, configured, and running on the Gateway node being restored.
The target Gateway Database must be installed if using the "-db" flag.

Stop the target Gateway node.
Log in to the Gateway:
Appliance Gateway:
Log in as
ssgconfig
and then open a privileged shell.
Software Gateway:
Log in either as the
root
or
layer7
user.
Run the following command:
# /opt/SecureSpan/Gateway/config/backup/ssgmigrate.sh 
[options]
Refer to the table below for a list of 
[options]
. Separate each option with a space.
If you are migrating a previous version:
 When migrating an image created in a previous version of the Gateway, you must upgrade the database after the migration is complete:
Access the Gateway main menu.
For appliance Gateways, select option 
2
 (Display Gateway configuration menu).
For software Gateways, proceed to the next step. 
Select option
1
(Upgrade the Gateway database). Follow the prompts on the screen to upgrade the database.
Restart the Gateway node.

In the routing assertions, use the
${gateway.cluster_property_name}
 context variable instead of explicit hostnames or IP addresses. For example, use
http ://${gateway.back_end_app_server}/Url/
 in the Route via HTTP(S) Assertion instead of the actual URL.
Using Manage Cluster-Wide Properties, define
back_end_app_server
as a new cluster property with the name of the source server as its value. For example:
DEVappserver.company.com
Follow the steps in this topic to migrate the policy between the testing and production servers.
When the migration is complete, update the value of the cluster property used for the routing URL in the mapping file—for example:
QAappserver.company.com

IP addresses referred to in routing assertions in the policies of published services
Values of cluster-wide properties

Use the Backup Utility (ssgbackup.sh) with the "
-it
" option. For more information, see Back?Up Gateways.
Open the mapping file in a text editor and replace
only
the placeholders with your values. The placeholders are indicated by "
_add_your_value_
" within the mapping file. Do not change anything else.
After the mapping file is edited, you specify it using the "
-mapping
" option of the system migration script.

<?xml version="1.0" encoding="UTF-8"?>
<L7flash:ssgimportmapping xmlns:L7flash="http://www.layer7tech.com/migration/stagingmapping">
   <L7flash:backendipmapping>
      <L7flash:ipmap sourcevalue="_add_your_value_" targetvalue="_add_your_value_"/>
      <L7flash:ipmap sourcevalue="_add_your_value_" targetvalue="_add_your_value_"/>
   </L7flash:backendipmapping>
   <L7flash:globalvarmapping>
      <L7flash:varmap name="babou" sourcevalue="_add_your_value_" targetvalue="_add_your_value_"/>
   </L7flash:globalvarmapping>
</L7flash:ssgimportmapping>