Pre-migration Actions
Before starting the migration, ensure that you read and understand the following points and take appropriate actions wherever necessary:
1. If any of the following are defined in source org and used in any ServiceMax configuration items identified for migration, migrate them to the target org (using Salesforce tools Change Set Deployment or Eclipse, or using ServiceMax configuration screens):
◦ Custom objects and custom fields in standard or custom objects
◦ Custom Apex web services / JavaScript code snippets (referenced in SFM Transaction or SFM Custom Action)
◦ Field Sets defined for any custom or standard objects (referenced in SFM Transaction)
◦ Images / Documents referenced in Output Document Templates
◦ Any dependent configuration items of SFM Custom Actions such as VF page and Apex class (referenced in SFM Wizard)
2. Identify custom SFM Mappings which have any lookup fields mapped to values (specific records in source org).
3. As migrating Timesheets also migrates (overwrites) the associated Business Hours to the target org and activates it if inactive, ensure that there are no Business Hours with the same name used in other configurations or apps in the target org.
4. ServiceMax recommends that you migrate entities in batches instead of selecting all configurations for migration in one go, especially for export and import actions.
5. Check the target org's GBL037 setting value and be informed of the impact of migration in Output Document processes. During Opdoc process migration, one of the following will occur based on the GBL037 setting value in the target org:
◦ If it is set to True, the Opdoc template is uploaded in the Salesforce file format.
◦ If it is set to False, the Opdoc template is uploaded as an attachment.
6. The migration tool identifies the selected configuration record as unique based on its ProcessID. Following are the examples:
◦ Target org has the SFM process with the name ‘Debrief WO’ and ProcessID ‘Debried_WO.’ Start migrating the SFM process from source org that has the name ‘Debrief WO’ and ProcessID ‘Debried_WO_New.’ Once the migration is successful, the new SFM process is created with the name ‘Debrief WO’ and ProcessID ‘Debried_WO.’
◦ Target org has the SFM process with the name ‘Service WO’ and ProcessID ‘Service_WO.’ Start migrating the SFM process from the source org that has the name ‘Service WO New’ and ProcessID ‘Service_WO.’ A warning message is displayed about the existence of a similar record during validation.
◦ Migration of SFM having RecordType field is successful if the field is available in Target org for the object.
 |
If you have any existing SFM configurations created from a flash-based designer, which has the same process name but a different process ID, then rename the configurations to make them unique. As long as the process ID is unique, the migration is not impacted. But the new HTML designer does not allow you to edit and save two configurations with the same name.
|