Migrating delta data after an upgrade
The Delta Data Migration utility is used in the last stage of the upgrade process to move data that was created or changed after copying the production database from your production server to the staging server.
Delta data refers to any data changes that occurred on the production server during the upgrade of the staging server. Using the staged upgrade method, a staging server is created as an exact copy of the production server at a specific point in time. Then, the active applications on the staging server can be upgraded to the target versions without affecting the current production server. While the staging server is being upgraded, the production server continues to run. Then, changes that occurred on the current production database while the staging server was being upgraded are applied. After validation, the staging server becomes the new production server. This greatly minimizes production server downtime, because the production server needs to be taken offline only long enough to perform the delta data migration to move the latest data onto the staging server.
Overview of delta data migration tasks
The delta data migration comprises the following major tasks. You should perform these tasks in a non-production environment, for validation purposes, before you perform the upgrade for the staging and production servers.
- Set up the staging server.
- Upgrade the staging server to the target software versions.
- Validate the upgraded staging server.
- Restore the staging server to its state before validation, and then apply any required corrections.
- Prepare the destination server for delta data migration.
- Run the Delta Data Migration tool to load data that changed while the staging server was being upgraded.
- Promote the staging server to production.
- Use the new image.
The following figure provides a high-level overview of the migration process:
- The "Staging server" column shows that you start the process by setting up and upgrading the staging server.
- The "QA/Validation" column shows how you then validate the upgrade and perform the delta data migration.
- The "Production" column shows how you end the process by promoting the staging server to production.
Components of the Delta Data Migration tool
The Delta Data Migration tool that is included with BMC Remedy Migrator consists of the following components:
- Configuration.xml: The file that the DeltaMigration.exe executable uses to run the correct package versions from the Packages folder.
Add C:\Program Files\BMC Software\migrator\migrator to the Path variable in your computer settings.
Update the Configuration.xml file with the Migrator installed directory path:
migrator-dir="C:\Program Files\BMC Software\migrator\migrator\DeltaDataMigration"
- DeltaMigration.exe: The executable that is run to compare or migrate your data from the current production server to the staging server (new production server).
The Delta Data Migration utility consists of the following folders, which are store under <MigratorInstallFolder>\Migrator\migrator\DeltaDataMigration:
- Packages: Contains the package, instruction XML files and the mapping files for all supported versions of the following products. See also the section below, "What is included in the application package."
- BMC Remedy AR System
- BMC Atrium
- BMC Remedy ITSM
- BMC Service Level Management
- BMC Service Impact Manager
- Integration for BMC Remedy Service Desk
- BMC ProactiveNet Performance Management
- BMC Service Request Management
- BMC Remedy Knowledge Management
- Utilities: Contains two utilities that can be used to find and package custom forms from your server:
- Custom forms packaging utility
- A count utility (AREntryCounter)
Do not modify the contents of any folders, unless directed to do so by BMC.
What is included in the application package
Each application package (BMC Remedy AR System, BMC Atrium Core, BMC Remedy ITSM Suite, BMC Service Request Management, and BMC Service Level Management) includes:
- One package XML file: Lists the instruction files that need to be executed in order.
- Many instruction XML files: Provide details for the forms that have data that is being migrated. Each package XML file references one or more of these instruction files.
- .arm files: The field mapping files. One or more instruction files refer to these .arm files.
The instruction files contain the following information specified for each form:
- Source and destination form name
- Unique field IDs
- Qualification to be used to migrate the data:
'6' >= "<DATE>"
which is Last Modified Date.
- A migrate option, which is set to Update (This option updates existing records if the same record is already present and creates new records if the same record is not present.)
- An option set to not trigger any workflow during the migration
Mapping files are created in these situations:
- For forms that need mappings for newly created required fields (fields where a default value is required) in applications
- For any field needs to be mapped to a different field in the destination server
- For handling data transformation changes between product versions
If no mapping files are referenced in the instruction files for a form, the migrator moves data from all fields on the production server to the staging server.
Following is an example instruction XML file:
<data enabled="true" source-form="FIN:ConfigRules" destination-form="FIN:ConfigRules" type="data" mode="search" merge-option="update" ignore-required-fields="true" ignore-pattern-matching="true" count="0" disable-related workflow="true">}} <qualification>PASS_QUALIFICATION</qualification> <unique-fields> <field id="270002020"> <field id="1000000001"> </unique-fields> <ports enabled="true" list="LIST_PORT" fast="FAST_PORT"> </ports> </data>
A package XML file is created that lists the instruction XML files and specifies their execution order.