TRY SERVICEDESK PLUS MSP FREE FOR 30 DAYS
DOWNLOAD NOW
REQUEST DEMO|GET QUOTE|LIVE DEMO|VISIT WEBSITE
Masterclass 2022 Switch to User Guide >

    Limitations 

    This guide documents the various limitations encountered during & after migration and mentions the workaround for limitations whenever possible. The guide is mainly split into 3 sections:

    Module Data Migration Limitations 

    All Modules 

    • Requests/Changes/Projects/Tasks created over templates that failed during migration will not be migrated.
    • Associations between requests and changes will not be migrated.
    • No maximum limit for adding attachments but the total attachment size of one entity(all attachments included) must not exceed 48 MB. Attachments greater than 48 MB will not be migrated.
    • While migrating module data, the history tab details will not be migrated.
    • If the lesser than sign (<) is followed by characters such as ! , -, \ , or alphabets, the lesser than sign will be removed during migration, except in rich text fields.
    • For example, text< will be migrated as text< and text<1 will also be migrated as text<1.
    • However, text<a will be migrated as texta and text<! will be migrated as text!
    • For additional fields (picklist, checkbox, radio, multi-select fields):
      • Special characters such as ` ~ # % ^ & * ( ) = + ? [ ] { } | ; " " will be removed from the options during migration as they are not supported in Cloud.
      • If the option contains only special characters mentioned above, the additional field will not be migrated.
      • Dummy entry will be added if the field option is empty.
    • In entities other than Incident, Service, Assets, and Workstations, user-defined fields of type radio, checkbox, and decimal will be migrated as picklist, multi-select, and single line fields respectively.
    • If the default value of an additional field exceeds the field character limit, the additional field will not be migrated.
    • Migrating additional fields is limited to the maximum number of fields supported in the Cloud version.
    • The migration will fail for requests/changes/projects and their templates that contain additional fields whose values exceed the specified constraints. This occurs mainly when the constraints of the field are updated after the request/changes/projects/template was created.
    • To avoid this scenario, you can manually update the additional fields as mentioned below when the migration is paused by the system after admin entities are migrated:
    • In Cloud, update the additional fields to contain the previous constraints.
    • Alternatively, in On-Premises, update the additional fields in requests with proper values before initiating module data migration.
    • The maximum allowed value for various fields across the tasks and service templates in Cloud are listed in the table below:

    Module

    Field Name

    Maximum Allowed Value

    Tasks (General Tasks, Request Tasks, Change Tasks, Project Tasks, Problem Tasks and Milestone Tasks)

    additional_cost

    9999999999999999

     

    estimated_effort_days

    9999

     

    estimated_effort_hours

    999

     

    estimated_effort_minutes

    999

    Service Templates

    Service Cost

    1000000000000000

     

    Question Option Cost

    1000000000000000

    Accounts/Customers

    • A maximum number of 500 accounts can be migrated to ServiceDesk Plus MSP Cloud.
    • Customer Domains will not be migrated from Service Desk Plus MSP On-Premises.
    • Archived customers will be migrated as Active Customers in ServiceDesk Plus MSP Cloud.

    Home 

    • In delegations such as backup approver, only the upcoming delegations will be migrated.

    Tasks (General, Request, Change, Project, Problem)  

    • Task templates that are not associated with any Requests or Projects will not be migrated.
    • Circular tasks & task templates cannot be migrated and will result in the following error: Cannot add the selected dependency as either a direct or an indirect dependency already exists between the source and the target node.
    • The Notify before scheduled start field in On-Premises will be renamed as E-mail me Before Schedule Start in Cloud.
    • The task reminder email will be sent once to the respective task technician after migration as configured in the Email Before field.

    Requests 

    • Request dependencies and notes attachments will not be migrated due to feature unavailability in Cloud.
    • By default, system notification for requests will not be migrated from build version 14202.
    • Requests that have the scheduled start time or scheduled end time set before the created time will not be migrated.
    • After migration, revisit the failed requests and update them with valid dates and time in scheduled start time and scheduled end time fields and initiate migration again. Use the following query to instantly update the created time earlier than the scheduled start time:
    •  update workorder set createdtime = scheduledstarttime-1000 where scheduledstarttime <createdtime and helpdeskid=<helpdesk id of the instance where migration is done>; 
    • Association between linked requests will not be migrated.  
    • Trashed requests will not be migrated.
    • Approvals, dependency, and resource details of Archived Requests will not be migrated.
    • Attachments that are not present in the mentioned file attachment path will not be migrated.
    • Resolutions exceeding 65536 characters will be trimmed to 65536 characters.
    • Only the first 100 email IDs in requests and the first 50 email IDs in notifications will be migrated. Other email IDs will be trimmed during migration.
    • SLA associations will be migrated if they are configured manually in Cloud. However, escalation mail will not be sent and SLA related actions will not be performed post-migration.
    • When approval data is migrated, actions like approve, reject, and send notification cannot be performed if the approver had been a non-system user in On-Premises.
    • Empty approval stages will be skipped during migration and the stages above them will be migrated with their original level ID.
    • For example, if stage 2 has no approvals, then stage 2 will not be migrated but stage 3 will be migrated as stage 3 and will be shown as stage 2 in the UI.
    • When empty approval stages are migrated with a request, the approval actions or email might not be triggered for the request in Cloud after migration. To avoid this scenario, delete or reorder the empty approval stages by editing them in On-Premises before initiating migration. 
    • In canceled requests, tasks that are not in a completed status (closed, canceled, resolved, or custom completed) will be moved to Canceled status during migration.
    • The Site-Group-Technician validation will be skipped during migration.
    • For example, if a technician is removed from a site/group, the requests from the site/group will be retained under the technician's scope during migration unless updated manually.
    • Requests in deleted departments will be moved to the department of the requester.
    • Rich text in worklog description field will be migrated as plain text with format loss.
    • If the technician who scheduled a request in On Hold status is deleted from the application, the request will be assigned to the technician who initiated the migration.
    • If a request template was modified after raising the request, the request will also be modified accordingly during migration.
    • For example, if a new field is introduced in the template, it will be also be reflected in the past requests associated with the template.
    • In On-Premises, the departmental roles are resolved based on the requester's department in a request. In Cloud, the same is resolved based on the request's department.
    • For example: If a request approval is configured to a department incharge, in On-Premises it is sent to the requester's department incharge whereas in Cloud it is sent to the request's department incharge.
    • Links present in notifications will be migrated as such. They will not be transformed as Cloud-compatible links.

    Changes 

    • Post-migration, the change ID sequence will be modified to match the existing sequence in Cloud instance.
    • To retain the Change ID during migration, contact our support team at servicedeskplus-cloud-support@manageengine.com. 
    • Attachment - related closure rules for Changes will not be migrated.
    • User association to Change Role will fail for 'Support Groups' role type due to feature unavailability in Cloud
    • CAB Members without login will not be migrated. If all the members of the CAB do not have a login, CAB migration will be skipped.
    • Provide IAM accounts and login for all CAB Members before initiating migration. 
    • While migrating change requests in Submission stage, users will be removed from their respective fields if any of the condition below is fulfilled. However, if the change request is in any other stage, the user will be retained.
      • If the user assigned to a change role is migrated as a requester or removed from the role/organization.
      • If the user assigned to an SDChangeManager role is migrated as a requester or removed from the role/organization.
      • If the user assigned to a technician-specific role is migrated as a requester or removed from the role/organization.
    • If the approval level is in Pending Approval status and the approver is a non-login user, the approval will be converted to To Be Sent status during migration.
    • During migration, if the percentage of approvers denied matches the approval auto-rejection rule configured in Cloud, the approval level will be auto rejected in Cloud.
    • Change requests that are not in Approved/Denied status will be displayed with empty status after migration.
    • The number of tasks migrated for a change request is limited to 300.

    Projects 

    • The maximum allowed value for various fields across the projects in Cloud are listed in the table below.

    Module

    Field Name

    Maximum Allowed Value

    Projects

    estimated_hours

    99999

     

    actual_hours

    99999

     

    estimated_cost

    999999999999

     

    actual_cost

    999999999999

    Projects > Milestones

    estimated_hours

    99999

     

    actual_hours

    99999

     

    Solutions 

    • Solution Owner field and Workaround type will not be migrated due to feature unavailability in Cloud.
    • If a solution is associated with one or more Account Group, the same solution will be created with the customers associated with the account group.
    • Since the Description field is mandatory for Solutions in both On-Premises and Cloud, a dummy entry will be added for empty description fields during migration.
    • If the Review Date is set on or after the Expiry Date, the solution will not be migrated.

    Assets 

    • Workstations/Virtual Machines/Virtual Hosts having duplicate service tags cannot be migrated straight away. However, we can include such service tags under Setup > Probes and Discovery > General > Invalid Service Tags and then perform migration to ensure all the machines are brought in from OP.
    • Virtual Machines without Virtual Hosts will not be migrated as Virtual Hosts are mandatory in ServiceDesk Plus MSP Cloud.
    • Assets with In Use state will get migrated as In Store if the associated user is resigned and it was not associated with any department or the associated department is not available for further use and it was not associated with any user.
    • Asset module of a particular instance-type in the on-premises will get migrated only to the same instance type in the Cloud version.
    • If any of the following conditions fail, the corresponding date field in Assets will be set as null:
      • Expiry date should be greater than the acquisition date.
      • Warranty expiry date should be greater than the acquisition date.
      • Warranty expiry date should be less than the expiry date.

    Maintenance 

    • Maintenances created over templates that failed during migration will not be migrated.
    • Schedules configured in maintenances will not be migrated. Users can configure schedules manually for maintenances post-migration.

    Reports 

    • Query reports will not be migrated.

    Purchase Order 

    • In purchase orders, only 5 approval level stages can be migrated as in cloud the approval stages are limited to only 5 levels. The rest of them are migrated and shown as read only fields after migration.
    • The value of place in PO is the default value and cannot be added to the purchase api of OP, hence place field cannot be migrated.

    Contract 

    • Contract renewal should have a unique name in Cloud. So the contracts which have duplicate names will not be migrated.
    • The child contract should have a time period within the parent contract. The Expired parent contract cannot have the child contract.
    • The contract renewal sub entity data is migrated from OP but the history of contract renewals is not shown in the Contract Renewals list view.
    • The parent and child contract should have the same vendor during migration.
    • The numeric additional field can only have up to 15 digits more than the range will cause failure.

    Problem 

    • The following problem data will not be migrated:
      • Problem Admin entities (Additional Fields, Custom Trigger, Notification Rules,Closure Rules,Problem Template,Problem custom functions)
      • Problem Solution and Workaround
      • Problem Notifications
      • Problem Associations
    • Rich text in the worklog description field will be migrated as plain text with format loss.

    Admin Data Migration Limitations 

    ESM Directory 

    Organization roles will be migrated. However, mapping of users with organization roles is currently not supported.

    In the Approvers field in template approvals, PM tasks and Field And Form Rules, organization roles other than COO, CEO, CFO, CIO will be migrated to equivalent organization roles of Request in Cloud,

    Example:

    • Site Incharge/Manager will be migrated as SIte Incharge/Manager of Requester
    • Regional Incharge/Manager will be migrated as Regional Incharge/Manager of Requester

    Users  

    • User profile pictures will not be migrated.
    • When associating a user with the Account Manager role, the MSP Requester Role will be added based on the available permissions in On-Premises.
    • When migrating roles, the permissions in the On-Premises version that do not have equivalent or similar permissions in the Cloud version will be skipped.
    • When migrating roles, characters that are not supported in the Cloud version will be discarded from the role names.
    • Migrating user additional fields are limited to the maximum number of fields supported in the Cloud version.
    • Login permissions will be migrated if a user belongs to the migrating organization in the cloud app.
    • The common user additional fields defined in the On-Premises version will be added to both requester additional fields and technician additional fields as the Cloud version does not have common user additional fields.

    Sites

    • In Service Desk Plus MSP On-Premises, the default site of an account can be under Refer settings, but in Service Desk Plus MSP Cloud, the default site of the customer will always be the custom site.

    Support Groups 

    • Support Group's name should not be greater than 50 characters.
    • Active Support Group will be migrated as inactive support group if there are not technicians configured.
    • Support Group's email address and sender name should satify the regex.
    • Support Group's sender name and sender email id will not be migrated if any of them is empty.

    Helpdesk Customizer  

    • The Change Manager field under Category will not be migrated due to feature unavailability in Cloud.
    • Color code in Priority is mandatory in Cloud but not in On-Premises. During migration, a random color value will be set for priorities without a color code.
    • The tuple limit for checklists is as follows. If the limit is exceeded, the entity will fail to migrate.
      • 100 checklists
      • 500 checklist items
      • 25 options in radio checklist items
      • 250 characters in single line checklist items

     

    • Only checklist items associated with a checklist will be migrated.
    • If a category is associated with one or more Account Group, the same solution will be created with the customers associated with the account group.
    • The number of checklist items migrated for a checklist is limited to 25.
    • In requests and request templates, a maximum of 25 associated checklists will be migrated.
    • If a checklist containing a deleted checklist item is associated with a request and the request is migrated, the checklist item will be created in a deleted state under Setup > Customization > Checklists > Checklist Item and mapped with the request.
    • The user who initiated migration will be added in the Created by field of checklists under requests and archived requests.
    • If the On-Premises user details who created or updated the checklist fails to migrate, the user who initiated migration will be added in the Created by and Updated by fields.
    • Holidays are dependent on Sites. Holidays entity should be migrated after site entity migration to avoid failures.
    • Color Option for Leave Types is not migrated.
    • The holidays added under default settings in Service Desk Plus MSP On-Premises, will be created in the Default Holiday Group of each customer in Service Desk Plus MSP Cloud.

    Incident/Service Management 

    Request Additional Fields Limitations  

    • If fields with the same name are found under Incident-Additional fields and Service-Additional Files, then only the incident field will be migrated and the service field migration will fail subject to the following conditions:
      • This failure will not affect the request templates when both fields are of the same type and contain the same constraints.
      • If the field types are different, then the value of the service additional field will be validated using the constraints of the corresponding incident additional field with a possible migration failure.
      • If the migration fails for any other reason then the migration of the templates containing those fields will also fail.
    • As additional fields are common for both incident and service templates in Cloud, duplicate additional fields in incident and service templates in On-Premises will not be migrated.
    • Radio type request additional fields will not be encrypted in Cloud.

    Template Limitations  

    • The following data will not be migrated due to feature unavailability in Cloud:
      • Form color and font in Incident and Service Templates
      • Help text for sections and fields in Incident and Service Templates
      • Incident and Service Template icons
      • Short description or any instruction, notes, or guidelines for Technician/Requester in Incident and Service Templates
      • Template Actions in Service Templates
    • You can associate only up to 200 tasks to an incident/service template.
    • If one template is associated with Multiple customers, All Customers or Account Group, the same template will be created under the each associated customers or all customers or the customers associated with the account groups.
    • $EmailSignature and $ITService will not be resolved in Reply Templates due to feature unavailability in Cloud.
    • On Behalf Of field will be added to all request templates during migration if the feature is enabled in On-Premises.
    • Fields that are not present in On-Premise's template layout (Created Date, Completed Time, Responded Time, Dueby Date, Response Due by, and Attachments) will be added to the Cloud templates during migration.
    • Fields such as Schedule Start Time and Schedule End Time field will be added to the technician layout of the Cloud template during migration.
    • Template SLA associations will not be migrated.
    • Software options in resource questions will not be migrated.
    • Cloud does not have PII (personally identifiable information) support for check box questions.
    • Drop-down and radio-type questions will be migrated as select box questions with PII support.
    • The tuple limit for service template resources is as follows:
      • 20 resources per template. If the tuple limit is exceeded, Error 4018 will be thrown.  
      • 20 questions per resource. If the tuple limit is exceeded, Error 4018 will be thrown.  
      • 300 options per question. If the limit is exceeded, ARRAY_SIZE_OUT_OF_RANGE error will be thrown.
    • In On-Premises, users without login access can be set as service approvers. However, in Cloud users must have login access to be service request approvers, this mismatch results in request templates migration failure if users without login access are present in approval levels of the templates. Provide login for all service approvers or remove users without login from the approvers' list in request templates before initiating the migration.
    • While migrating data from On-Premises Standard Edition to Cloud Standard Edition, the Service Category field in incident templates and the Service Category admin entity will not be migrated due to feature unavailability in Cloud.

     

    Field And Form Rules Limitations 

    • Field And Form Rules names are global to all request templates and case-insensitive in Cloud. Therefore, if two Field And Form Rules have different letter casing in On-Premises, they will be considered as duplicates. The second Field And Form Rule will not be migrated and result in Error Code 4008.
    • Manually edit the Field And Form Rules names in On-Premises to contain different names.

    The following limitations are employed in the event, conditions, and actions sections:

    Field And Form Rules Section

    Limitation

    Event

    Field And Form Rule will not be migrated when the event is set as 'On Field Change' in the following cases:

    •If Service Approvers field is configured.

    •If Reason field is configured and the rule execution is set for 'On Create/Edit' or 'On Create' operations.

    Conditions

    To Be Sent status is not supported for Approval Status criteria.

    If the criteria contains Logged-in User Details/User details (username, email id, department)/Site/Group/On Behalf Of fields, it will result in an error since these fields are text fields in On-Premises and look-up fields in Cloud.

    is_empty and is_not_empty criteria for Date/Time fields will not be migrated.

    Actions

    Field And Form Rule actions except custom script actions will be migrated. If a Field And Form Rules contains only custom script actions, it will result in No Valid actions found error.

    Field-specific actions such as Enable Fields, Disable Fields, Hide Fields, Show Fields, Mandate Fields, Non-Mandate Fields, and Clear Fields are not supported for Assets, Requester, and On Behalf Of fields in Cloud.

    Set Field action is not supported for DueBy Date, Group, and Site fields in Cloud.

    Mandate Fields and Non-Mandate Fields actions are not available for Site field.

    Field And Form Rule will NOT be migrated if:

    •The action is configured for Service Approvers field and the rule execution is set for On Edit operations.

    •The action is configured for Reason field and the rule execution is set for On Create operation.
    •  If the value of criteria is set as Not Specified, it will be migrated as is_empty criteria. If there are multiple values in addition to 'Not Specified', is_empty criteria will be added as child criteria. 
    •  If the value of criteria contains text separated by a comma, it will be migrated as such. However, on editing, the values will be automatically updated as separate values. 
    •  If Not Specified is configured as Set Value action, it will be migrated as Clear Field action to Cloud. 

    Change Management 

    • $AllTechnicians role in Change Templates will not be migrated due to feature unavailability in Cloud.
    • Change Field And Form Rules will not be migrated.
    • The number of CAB members is limited to 100.
    • The Notify to field in change status is limited to 200 roles.
    • The number of change roles associated with a change template is limited to 1000 users.
    • In reason_for_change there is a naming difference for the pre-populated record Upgrades based on technology changes so this will be created as a new record.
    • Change roles will have view permission enabled for all stages after migration.
    • The Stage and Status field in change templates will be set as Submission stage and Requested status respectively in Cloud.
    • By default, change requests and templates are not migrated with their workflow. If a workflow with the same name as in On-Premises is created in the Cloud, the change request/templated will be linked accordingly.

    Asset Management 

    • Default product types that have their names changed will be migrated with their default name.
    • For example, if a default product type workstation is changed to workstation1, on migration the name will be changed to its default name workstation itself.
    • Similarly, custom product type with default product type name will be changed to name_id.
    • Radio button is not supported in Asset Additional fields.
    • Managed Software is migrated but the other types are not considered as of now.
    • In Cloud, the web URL in vendor needs to start with either "http" or "https" and should be of valid format. If there is a mismatch, the migration results in the following error: PATTERN_NOT_MATCHED.

    Integrations 

    • The migrated data in Cloud will not be synced with Zoho Analytics.
    • Post-migration, navigate to Setup > Apps & Add-ons > Zoho Analytics > Settings and reset the data using the Clean Up and Sync Now button.

    Maximum Character/Entity Limits in Cloud   

    The character count in the following fields is limited to the maximum number of characters supported in the Cloud version. If the count exceeds the mentioned limits, the characters will be trimmed accordingly during migration:

    • Task worklog description will be trimmed to 3000 characters
    • Request Template comment will be trimmed to 250 characters.
    • Request approval comments will be trimmed to 1000 characters.
    • Cancel flag comment, On-hold scheduler comment, Closure comment, and Closing comment (Request acknowledge comment) will be trimmed to 250 characters.
    • Service category description will be trimmed to 100 characters.
    • The description of the following change admin entities will be trimmed to 250 characters: change risk, reason for change, change closure code, stage and status, closure rule, and change template.
    • The maximum limit of entities allowed to be migrated in Cloud is as follows,
    • Status: ["75"]
    • Priority: [ "150"]
    • Task Type: ["50"]
    • Worklog Type: ["100"]
    • Category: ["1000"]
    • Subcategory: ["5000"]
    • Item: ["15000"]
    • Urgency: ["75"]
    • Impact: ["75"]
    • Level: [ "750"]
    • Mode: ["300"]
    • Requester Closure Code: ["100"]
    • Reply Template: ["300"]
    • Resolution Template: ["300"]
    • Request Type: ["2500"]   

    Zoho Corp. All rights reserved.