This documentation supports the 9.0 version of BMC Remedy ITSM Deployment.

To view the latest version, select the version from the Product version menu.

Performing the data migration

The following topic are provided:

Migration guidelines

Note the following guidelines and limitations for migrating data:

  • Use the same Admin user account to log on to both servers. The upgrade environment is a database restore of the production environment. To help you track and debug issues, use one user account to do the migration. If you use Demo, use the same password for both servers for that administrator account.
  • You can run the Delta Data Migration Tool one time or multiple times. BMC recommends that you run the tool at least twice: once before you start your production outage, and again after the production outage begins. The first data migration moves all of the data that has been added or changed since you made the production backup. The second migration moves only the data that has changed since you started the first data migration. This method ensures that the time required to do the data migration (your outage window) is as small as possible.
  • During delta data migration, when you select Compare, a comparison result report is created. This report can be used to identify all the data that has been created or updated in the source server during the delta time period. The comparison script generates an .xml result file for each instruction .xml file with the instruction name and suffix _Compare; for example: Remedy_Service_Request_Management_Compare.xml.
    The script generates a compare .xml result file for each instruction .xml file. These files include all the data entries that are either different (records updated in the source server during the delta period) or missing (records created in the source server during the delta period) in the destination server.

To configure your system for improved migration performance

The Migrator Configuration.xml file (located in the migrator folder under <MigratorInstallDirectory>) contains the count-enabled attribute that executes select count(*) queries by default and calculates the percentage completion (for every 100 records) that is shown in the MigratorCLI command window.

To improve performance if you have a large number of records (and get the total number of records that are migrated), perform the following configuration before running delta data migration (DDM).

  1. Open the Migrator Configuration.xml file.
  2. Set the count-enabled attribute to false.
    With this setting, you see only the total number of records processed instead of the percentage; for example:

    <count enabled="false" />

    After you perform this configuration, you can no longer see the percentage of the migration that is finished while DDM is running. To see the percentage of the migration that is finished while DDM is running, set count enabled back to true.

To migrate the data

Use the Delta Data Migration Tool to migrate data from the production server (the source server) to the staging server (the destination server) as follows:

  1. Go to the <MigratorInstallDirectory>\DeltaDataMigration folder.

  2. Double-click the DeltaMigration.exe file to open the Delta Migrations window.

  3. Click the button next to the Source Server field to open the Server dialog box.

  4. On the Server dialog box, complete the following fields, and then click OK.

    Source ServerName for the source server (the production server)
    User NameUser name for the source and destination servers (same for both)
    PasswordPassword for the source and destination servers (same for both)
    TCP PortDefault value used by the script. If no port is specified, the default is 0.
    Fast/List PortYou can change the default value of 390635.
  5. Click the button next to the Destination Server field to open the Server dialog box.

  6. Enter the destination server (staging server) information, and click OK.
    The Delta Data Migration tool validates the versions on your source and destination servers. It provides a list of all supported BMC Remedy AR System products and applications. Applications shown in red indicate that an appropriate package was not found or is not applicable for your server.


    The destination server data will probably not be consistent until all the data up to the current time is migrated. You can migrate the data in one or more "chunks" (using the Start Date and End Date fields in the Delta Data Migration Tool to specify the range of data to migrate).

  7. To ensure that the destination server data is consistent, enter an empty data range (which means the current time stamp) in the End Date field to migrate the final chunk of data.
  8. Verify that the Re-run applications with previous criteria & instructions check box is selected.
    This check box is selected even if you are re-running the migration after fixing data issues.


    • If you are using the multi-run approach to migration to minimize your downtime, after confirming that the previous DDM has finished successfully and is error-free, clear the Re-run applications with previous criteria & instructions check box.  At this point, DDM will migrate based on the new date and selection criteria that you have specified. If the previous DDM had errors, fix the errors and run the DDM again with the Re-run applications with previous criteria & instructions check box selected. The DDM is then based solely on the time stamp. 

    • Starting from Service Pack 1, Delta Data Migration (DDM) tool stores the last record ID in the memory for every chunk of data that is migrated. In case of termination due to user interruptions, network issues, or session timeouts the DDM stores this record ID in the <instruction_file>_LastSuccessfulID.txt file present in a Working folder under <MigratorInstallDirectory>\DeltaDataMigration. During re-run the record ID is retrieved from the <instruction_file>_LastSuccessfulID.txt file and the DDM continues the data migration from the next consecutive record.
  9. Select all applications that are not shown in red.

  10.  In the Fetch Data/Objects Created/Modified After Date fields, use the Start Date and End Date fields to enter a range of dates (so that you can migrate a "chunk" of data).
    The dates allow you to migrate only those records that were modified or created in that date range. If you are not migrating custom forms data, you can clear the Custom selection in the application name list.

    1. For Start Date, enter the time from when you want to transfer the data. To account for Daylight Saving Time, enter the Start Date and End Date with a time stamp that is later than midnight (for example, 1:00:00 AM).
      Data in the forms that are later than or the same as this time stamp are migrated. If this is the first time you are running the migration, the time stamp that applies is when the production server backup was used to create the staging server. If this is a multiple-run scenario, the time stamp that applies is when you initiated the previous run.

    2. For End Date, enter the date with the time stamp to when you want to transfer the data (for example,12/20/2012 1:00:00 AM).
      You can run the migration multiple times, as needed, to finish the DDM. For the final migration, do not enter an end date.
  11. To generate a report, select Data count validation.

  12. Click Migrate or Compare, and then click Yes.
    The Delta Data Migration window appears, showing the parameters that the Migrator will use. One command window is opened for each application you are running. The windows close automatically when the process is completed or an error occurs. The DeltaMigration.log file is created in the same location from which you ran the .exe file for the Delta Data Migration Tool.

  13. When you finish the DDM, navigate to the Working\Logs folder (by default, <MigratorInstallDirectory>\DeltaDataMigration\Working\Logs) to review the Count_statistics.csv file. 

    If you see errors in the report, see Reviewing migration results and resolving issues to fix them. If you want to rerun the migration or the comparison, you must wait for all of the command prompt windows to close before starting a new run.

Was this page helpful? Yes No Submitting... Thank you