When & How to use Data Migration to Upgrade your BMC Remedy Environment
To a 9.x fresh install Remedy Image/Server
This process and steps are only for the following use cases for an On-Premise OR a ROD (Remedy-On-Demand/SaaS) OR any Cloud Remedy implementation customer:
1. Customers who wants to change the Database from SQL Server to Oracle or from and to any database and want to have their data migrated between different databases.
2. Customers who have a highly customized pre 7.6.04 version environment and wish to install the latest version of the Remedy products in an environment and only want to create the customizations they want in the new server and migrate data between the servers.
3. Customers who have a high volume of data with older versions and only wish to migrate the AR Core and ITSM Foundation data to a fresh install of the latest version of products and use the old server for reporting purposes. They can optionally move a few months of open transactional data.
Please read the restrictions and ensure you follow this in the current Production server.
Restrictions after restoring the database on the staging server with overlays
- 1. Pick a date that is not the ‘product’ installed date from SOURCE server.
- a. For Foundation, Process and Template Data - The date used has to be greater than product installed date so OOTB data is not brought over and over-written and recommended date is submit/create date of your operating company.
- b. For Transactional Data , we have following recommendations:
i. If coming from pre-7604 versions - Migrate only AR, CMDB and ITSM Foundation data and no transactional data and use old system for reporting and audits.
ii. If coming from 7604 or greater – Migrate AR, CMDB and ITSM Foundation and 6 months OR 1 year transactional data and also use SQL queries provided to find out the oldest open tickets in all products to take action and to correctly determine the date to use for data migration.
iii. The process and tool is capable of moving all transactional data if really needed to be brought over but our recommendation is the above 2 options.
Performing data migration of large backend and custom forms
Disabling (setting ‘<data enabled="false" ‘) OOTB configuration forms
The system and configuration form(s) data is already installed in the destination server via the fresh install with the latest updates/additions and we do not want DDM to pick these data from the older source version server and overwrote in the destination server.
Forms list is in the ‘Appendix’ section in the last page of this document
CMDB Data Migration Planning
- 1. Ensure all Asset attributes are present in BaseElement and AST Attributes form in the current version and also ensure the data is synced between these forms.
- 2. Ensure all attributes in BaseElement form in the current version that are part of Asset are also present in the BaseElement form in the 9.x system.
- 3. Data Clean up -
o Cleanup orphaned data on AST:Attributes where ReconID exists in AST:Attribues but not in BMC_CORE_BMC_BaseElement
select assetID, reconciliationidentity from ast_attributes where reconciliationidentity not in (select reconciliationidentity from bmc_core_bmc_baseelement where datasetid = 'BMC.ASSET');
delete from ast_attributes where reconciliationidentity not in (select reconciliationidentity from bmc_core_bmc_baseelement where datasetid = 'BMC.ASSET');
o Cleanup AST:Attributes where ReconID is 0.
select assetID from ast_attributes where reconciliationidentity = '0';
delete from ast_attributes where reconciliationidentity = '0';
- 4. For CMDB custom classes/attributes, export (using CMDBDriver, xexpdf command) from source system and import them into target system.
- 5. For AST:Attribute form customizations, ensure you have them as overlays in your current version and then export and import the overlays (using dev studio) from source to the target system.
- 6. Validate BMC_BaseElement and AST:Attribute form attribute level mapping. Both forms should be in sync between 8.1.02 and 9.x system.
Enabling data migration of SRD forms
The below SRM/SRD forms are disabled by default in DDM, and if you are doing a fresh install and performing data migration, then you need to review the updated customer data on these forms and then enable them as needed for the data migration.
Form Names to Enable
ENT:SYS People Entitlement Groups
ENT:SYS-Access Permission Grps
SRD:SRDED PED Associations
You need to also update the additional qualifications from these forms in the xml file.
ChildType = "Process" OR 'ChildType' = "AOI" OR 'Assoc2FormID' = "SRM:ConditionInstance"
'302775700' = 3 OR '302775700' = 4 OR '301285000' = "SRM:ConditionInstance"
'Association Type' = "Runtime"
'10003037' = 0
Note: You should reverse the above once the initial data migration is complete and these forms have to be disabled for the ‘delta data’ DDM runs.
- 2. Run the AREntryCounter utility using that DATE to get the counts for each product.
- 3. Review the counts for each product and decide how many chunks of DDM runs you will have to do for each product. Document the date chunks. You can also use multiple windows servers with AR Migrator installed to run different date chunks/products in parallel to get great performance results.
- 1. Prepare TWO servers
a) An 8.1/9.x stack fresh install stack with no data (not even sample).
b) Staging server with current version (AR & DB) of customer DB backup restored.
- 2. Disable all processes on both servers (that would create/update data):
Server configuration adjustments before you start DDM
Other than what is documented in this section, you should also disable CMDB, Recon and SLM collectors in the armonitor.cfg file on the server.
Disable the following demons by placing a leading “#” on each line. The lines in the armonitor.cfg should look like this for the specific lines
Save the changes.
These should be disabled in ar.cfg file
- Disable DSO
- Disable Escalations
- Disable FTS (Full Text Searching)
- Disable Localized Server
- 3. Both the source and destination servers should be out of server group and NO other server should be connected to this DATABASE.
- 5. There should be NO data changes allowed in the Destination server.
PREPARE FOR Data Migration
- 1. Add custom forms and custom fields manually to the Destination server. Custom fields should be added to the overlay layer and this also includes custom selection field values for fields like – status/status reason
- 1. Create custom forms package if you have custom forms.
Extending Delta Data Migration to include customizations
- 1. Run the pre-ddm fixes. The SQL fixes has to be run before every DDM run
RUNNING THE DATA MIGRATION
- 1. Run DDM in chunks using start and end date for each product one by one (or you can combine some products if data volume is low).
Performing the data migration
- 2. Recommendation is to have a static SOURCE server with ALL STEP 3 processes/escalations turned off, and use that server as source server for DDM.
- 3. Re-run DDM for same date range and product selection when you are re-running DDM for errors. Also do not fix data errors in destination server, only fix in source server and DDM will bring it over.
Reviewing the migration results and resolving issues
- 1. Run DDM everyday form the live server in the last week before go live.
- 2. Run DDM 3-4 times before go live freeze on go-live weekend
- 3. Run final DDM run with source live server frozen.
- 4. Perform the post-DDM procedures
Post Migration Procedures
The post migration procedures need to be executed before you can start using the destination server. If you have a requirement of testing in the destination server before go-live then you need to take a DB backup + execute post migration procedures + do your testing + backup any fixes in def/arx files + revert to the DB backup taken before the this activity and then continue DDM runs. These procedures needs to be executed after final DDM run and before the server is used for any activity.
Forms that can be disabled in DDM for a Fresh install and data migration scenario in AR Core xml file
AR System Alert Delivery Registration
AR System Alert User Registration
AR System Current License Usage
AR System Email Association
AR System Email Attachments
AR System Email Error Logs
AR System Email Error Messages
AR System Email Failover Mail Server Configuration
AR System Email Instruction Parameters
AR System Email Instructions
AR System Email Messages
AR System Email Security
AR System Email Templates
AR System Email User Instruction Templates
AR System Historical License Usage
AR System License: Save Produse Attachment
AR System Message Catalog
AR System Searches Preference
AR System Skins: Skinnable Properties
AR System User Application Actor
AR System User Central File
AR System Version Control: Labeled Object
AR System Version Control: Object Modification Log
AR System Version Control: Object Reservation
AR System Version Control: Task
AR System Web Services Registry
AR System Web Services Registry Pending Delete
Business Segment-Entity Association
Business Time Holidays
Business Time Segment
Business Time Shared Entity
Business Time Workdays
Forms that can be disabled in DDM for a Fresh install and data migration scenario in
Atrium CMDB & Atrium Product Catalog xml files
Forms that can be disabled in DDM for a Fresh install and data migration scenario in ITSM Foundation xml files
AAS:CFG Notification Rules
CTM:People Template PG
CTM:Support Group On-Call
LIC:SYS-License Permission Map
NTE:CFG-Country Code Option
NTE:CFG-NT Events NonSupport
NTE:CFG-Numeric Pager Prefix
NTE:CFG-Pager Service Config
NTE:SYS-Define NT Events
SYS:Date Time Query Rules
SYS:Form Field Selection
SYS:Request Actions Assoc
SYS:Request Types Associations
SYS:Status Query Rules
SYS:Status Transition Rules