Before You Begin Migrating Data

the four ways to migrate data docid\ xtgsi12juvvrmrhtaj dyabout data migration docid\ xtgsi12juvvrmrhtaj dyconceptual information migration process overview docid\ xtgsi12juvvrmrhtaj dyitems excluded from migration docid\ tc5gktag s5yzd m7hmyh the four ways to migrate data before you begin migrating data, it is very important that you understand the different ways there are to migrate data there are four ways that you can migrate data enabling the ivanti service manager development project and applying a package with a package, you can migrate a very specific set of configuration changes for example, you can add service request data to a package and migrate it see appendix c using the ism development project to migrate data docid\ oazckiixxshugjnkpasik enabling the ivanti service manager development project and using the push link with this method, you can migrate master data, but not configuration data (because that is moved using packages) see appendix c using the ism development project to migrate data docid\ oazckiixxshugjnkpasik disabling the ivanti service manager development project and using simple mode with simple mode, you can only copy service request data and escalation schedules when you use simple mode, you copy all of the configuration data from instance of a tenant to another see how to use simple mode to migrate data docid\ stq b6ebnoc64jdl9kbiz disabling the ivanti service manager development project and using advanced mode with advanced mode, you can choose which items to copy, such as all business objects but not workflows however, you cannot specify which business objects (or whichever item you migrate) you can choose the type of items to migrate but not the specific items within that type with advanced mode, you can also specify if you want to migrate master data, which you can use to copy the contents of a business object see using advanced mode to migrate data docid\ stq b6ebnoc64jdl9kbiz we plan to remove simple mode and advanced mode in an upcoming release the ivanti service manager development project will then be the only data migration method available this is because simple mode and advanced mode only migrate the difference in data between the source and the target, and do not take into account the sequence of the data changes between the two systems this document includes information about migrating data using all of the methods listed above however, we highly recommend that you enable and use the ivanti service manager development project, and therefore, this document focuses on those processes about data migration the process of migrating data can be defined as moving information from the production instance of the tenant to the staging instance of the tenant, and then optionally moving information from the staging instance of the tenant to the uat instance of the tenant, and then finally moving information back to the production instance of the tenant (from either the staging or uat instance of the tenant) there are two scenarios production instance > staging instance > uat instance > production instance production instance > staging instance > production instance the migration process has three parts migrating data from the production instance of the tenant to the staging instance of the tenant this process is described in creating the first staging or uat instance of the tenant from the production instance of the tenant docid\ nk99nfacluuwabumozwcu migrating data from the staging instance of the tenant to the uat instance of the tenant although this step is optional, we recommend it this step is made up of two parts a migrating the metadata from the staging instance of the tenant to the uat instance of the tenant this process is described in appendix b migrating data from one tenant instance to another using simple mode or advanced mode docid\ stq b6ebnoc64jdl9kbiz b migrating the transactional data from the production instance of the tenant to the uat instance of the tenant this is the same process as creating the first staging or uat instance of the tenant from the production instance of the tenant docid\ nk99nfacluuwabumozwcu migrating data from the uat instance of the tenant to the production instance of the tenant (if you migrated from the staging instance to the uat) or migrating data from the staging tenant to the production tenant (if you did not migrate data to the uat tenant) this process is described in appendix b migrating data from one tenant instance to another using simple mode or advanced mode docid\ stq b6ebnoc64jdl9kbiz conceptual information migration process overview there are two scenarios when you perform the migration process when the customer initially purchases and provisions their system when you initially purchase and provision your system see about initially provisioning the production instance of the tenant docid\ xtgsi12juvvrmrhtaj dy when the database changes see about migrating data after creating the initial production instance of the tenant docid\ xtgsi12juvvrmrhtaj dy about initially provisioning the production instance of the tenant overview of initially provisioning the production instance of the tenant docid\ xtgsi12juvvrmrhtaj dyoverview of the initial production instance of the tenant creation process docid\ xtgsi12juvvrmrhtaj dy overview of initially provisioning the production instance of the tenant adding a tenant docid\ xtgsi12juvvrmrhtaj dy shows the process for migrating data from the initial production instance of the tenant (version 0 0) to the staging instance of the tenant, and then optionally from the staging instance of the tenant to the uat instance of the tenant, and then from the staging (or uat) instance of the tenant back to the production instance of the tenant this process establishes the first production instance of the tenant (version 1 0) see overview of the initial production instance of the tenant creation process docid\ xtgsi12juvvrmrhtaj dy for information about the numbered steps shown in adding a tenant docid\ xtgsi12juvvrmrhtaj dy adding a tenant things to note in adding a tenant docid\ xtgsi12juvvrmrhtaj dy the version numbers used in this example are for reference only the software residing on a tenant does not actually have the version numbers shown here version 0 0 of the production tenant represents the starting state of the production tenant immediately after it was created this version (or instance) typically does not contain any transactional (customer) data you can preconfigure the metadata by either using a customer template, or if no template is available, in a way that provides a default user interface look and feel examples of templates are a retail business template and a high tech template when creating the initial version (or instance) of the production tenant (version 1 0), the system usually bypasses the uat instance of the tenant because there is no baseline configuration to use as a reference for regression testing you do not make changes to configuration data and metadata directly in a running database on the production instance of the tenant instead, you copy the database to the staging instance of the tenant and makes the changes there the production instance of the tenant remains unlocked throughout the provisioning and configuration process so that you can update the production instance of the tenant with minimal overhead the system locks the production instance of the tenant for the first time after you verify the production readiness of the production instance of the tenant overview of the initial production instance of the tenant creation process the following sections provide a high level description of the initial production instance of the tenant creation process before starting the migration docid\ xtgsi12juvvrmrhtaj dystep 1a creating the initial production instance of the tenant (version 0 0) docid\ xtgsi12juvvrmrhtaj dystep 1b creating the initial staging instance of the tenant (version 0 1) docid\ xtgsi12juvvrmrhtaj dystep 2 updating the data on the staging instance of the tenant (version 0 1) docid\ xtgsi12juvvrmrhtaj dystep 3 pushing the data from the staging instance of the tenant (version 0 1) to the production instance of the tenant (version 1 0) docid\ xtgsi12juvvrmrhtaj dy before starting the migration determine the customer's system requirements to help you design the initial production instance of the tenant (version 0 0) determine your system requirements to help you design the initial production instance of the tenant (version 0 0) step 1a creating the initial production instance of the tenant (version 0 0) create the initial production instance of the tenant, called version 0 0 this initial production instance of the tenant contains basic help desk and other functionality based on industry standards and preliminary requirements version 0 0 is used as a starting point for additional configuration the process for creating the initial production instance of the tenant is described in how to create a new tenant docid\ xirrn6qvowheykrlb1zpw send an email to the customer with the credentials for and a link to the initial production instance of the tenant (version 0 0) step 1b creating the initial staging instance of the tenant (version 0 1) move the initial production instance of the tenant (version 0 0) to the staging instance of the tenant the version on the staging instance of the tenant is renamed version 0 1 the process for moving the initial production instance of the tenant to the staging instance of the tenant is described in appendix b migrating data from one tenant instance to another using simple mode or advanced mode docid\ stq b6ebnoc64jdl9kbiz timing this activity typically takes 5 days step 2 updating the data on the staging instance of the tenant (version 0 1) edit the metadata (and optionally configuration data) in version 0 1 on the staging instance of the tenant to meet your requirements ask the customer to validate the configuration on the staging instance of the tenant validate the updated configuration on the staging instance of the tenant timing this activity typically takes from two to twelve weeks step 3 pushing the data from the staging instance of the tenant (version 0 1) to the production instance of the tenant (version 1 0) remove any sample and test data that had been temporarily added to the staging instance of the tenant push the version 0 1 metadata and configuration data from the staging instance of the tenant to the production instance of the tenant, where it becomes the first fully functional release, called version 1 0 the process for moving the staging instance of the tenant to the production instance of the tenant is described in appendix b migrating data from one tenant instance to another using simple mode or advanced mode docid\ stq b6ebnoc64jdl9kbiz ask the customer to verify that the production instance of the tenant configuration (version 1 0) is ready to "go live " verify that the production instance of the tenant configuration (version 1 0) is ready to "go live " lock the production instance of the tenant, either after you receive the "go live" readiness confirmation or 10 days after the "go live" date if you do not receive any confirmation timing this activity typically takes from two to eight weeks about migrating data after creating the initial production instance of the tenant requirements before migrating data from the staging or uat instance of the tenant to the production instance of the tenant docid\ xtgsi12juvvrmrhtaj dyoverview of the data migration process docid\ xtgsi12juvvrmrhtaj dydata migration process overview docid\ xtgsi12juvvrmrhtaj dy requirements before migrating data from the staging or uat instance of the tenant to the production instance of the tenant ensure that you have completed the following requirements before you migrate data from the staging or uat instance of the tenant to the production instance of the tenant verify that the logs for the staging or uat instance of the tenant are free of all configuration related errors there cannot be any logs for quick actions, workflow, email, and so on, and there cannot be any “object reference not set to an instance of an object” errors ensure that all customer related integration details (such as emails, ldap, and vpn) have been documented and provided to the implementation team complete the information in the tab called email and integration and attach any associated documentation to the service request ensure that the implementation team completes the spreadsheet that lists the data to be cleared from the staging instance of the tenant before migrating the data to the production instance of the tenant this might include details such as “truncate the following tables", "delete when ", and so on update the standard objects spreadsheet complete a spreadsheet that lists the data to be cleared from the staging instance of the tenant before migrating the data to the production instance of the tenant this might include details such as “truncate the following tables", "delete when ", and so on update the standard objects spreadsheet ensure that a service request contains the required go live date this does not guarantee the go live date, but gives information about when it is planned the implementation team plans and communicates this to the solution/implementation manager provide a complete list of custom or updated reports export the rdl for all reports and attach it to the service request overview of the data migration process data migration process docid\ xtgsi12juvvrmrhtaj dy shows the steps that occur during a major update to a functioning production tenant instance (in this example, from version 1 0 to version 2 0) data migration process note the following the version numbers used in data migration process docid\ xtgsi12juvvrmrhtaj dy are for reference only the software residing on a tenant does not actually have the version numbers shown here version 1 0 of the production tenant instance represents a functional, running production tenant instance whose configuration remains unchanged until step 6 below data migration process overview this section describes the actions that occur when data is migrated to the production instance of a tenant before starting the migration docid\ xtgsi12juvvrmrhtaj dystep 1 docid\ xtgsi12juvvrmrhtaj dystep 2 docid\ xtgsi12juvvrmrhtaj dystep 3 docid\ xtgsi12juvvrmrhtaj dystep 4 docid\ xtgsi12juvvrmrhtaj dystep 5 docid\ xtgsi12juvvrmrhtaj dystep 6 docid\ xtgsi12juvvrmrhtaj dyafterward docid\ xtgsi12juvvrmrhtaj dyif a step fails docid\ xtgsi12juvvrmrhtaj dy before starting the migration work with the customer to create a comprehensive project plan describing the requested changes, change verification testing, project team contact information, schedule constraints, and other relevant information create a comprehensive project plan describing the requested changes, change verification testing, project team contact information, schedule constraints, and other relevant information step 1 copy version 1 0 of the production instance of the tenant in its entirety (that is, master data, metadata, configuration data, and transactional data) to the staging instance of the tenant the copied version on the staging instance of the tenant is renamed version 1 1 disable all email configurations (@customer mx domain) for the production instance of the tenant in the staging instance of the tenant, and enable the staging instance of the tenant email configuration (@tenantname stg saasit com) lock the production instance of the tenant the production instance of the tenant cannot be reconfigured until approved configuration changes are applied in step 6 while the production instance of the tenant is locked, no one can make changes that will affect the migration process or be overwritten by the new configuration shrink the data on the production instance of the tenant to 5gb or less the staging instance of the tenant is considered current and active timing this step usually takes five days step 2 edit the metadata (and optionally the configuration data) in version 1 1 to meet the customer's requirements edit the metadata (and optionally the configuration data) in version 1 1 to meet your requirements record the configuration details in a change register timing this step typically takes three weeks it takes two weeks to prepare and migrate the configuration from the staging instance of the tenant to the uat instance of the tenant, and one week within the uat instance of the tenant for final testing step 3 copy the transactional data (that is, customer data records) from the version 1 0 production instance of the tenant to the uat instance of the tenant and if necessary shrink the data to less than 5 gb use the transactional data to test the metadata and configuration data updates in step 5 version 1 0 metadata and other configuration data from the production instance of the tenant is not copied to the uat instance of the tenant timing this step typically takes three days step 4 ask the customer to approve the metadata push from the staging instance of the tenant to the uat instance of the tenant if the customer does not approve it, send the approval request again if the customer does not approve the request a second time, work with the customer to resolve any issues review and approve the metadata push from the staging instance of the tenant to the uat instance of the tenant send the customer a tenant instance configuration migration template to complete, which provides details about exactly what data should be migrated complete a tenant instance configuration migration template, which provides details about exactly what data should be migrated review the migration template push version 1 1 of the metadata and configuration data to the uat instance of the tenant only migrate the items included in the template this is a full metadata migration from the source to the target; that is, this is not a delta metadata migration lock the uat instance of the tenant, making it read only and under change control timing this step typically takes at least one week step 5 ask the customer to perform acceptance testing on the uat instance of the tenant using version 1 1 metadata and configuration data combined with version 1 0 transactional data the customer performs the tests based on documented use cases to ensure that the configuration is "go live" ready perform acceptance testing on the uat instance of the tenant using version 1 1 metadata and configuration data combined with version 1 0 transactional data performs tests based on documented use cases to ensure that the configuration is "go live" ready the customer verifies that the uat instance of the tenant configuration and logs are "go live" ready do not update the production instance of the tenant if the uat instance of the tenant is not "go live" ready based on predefined requirements verify that the uat instance of the tenant configuration and logs are "go live" ready do not update the production instance of the tenant if the uat instance of the tenant is not "go live" ready based on predefined requirements all logs on the uat instance of the tenant must be clear of any configuration related failures for example, there should be no logs reporting failures in workflows, quick actions, email, object references not set to instances of objects, and so on you must approve all configurations the customer must provide documentation describing integration details and attach it to the service request documentation must include the completed migration template, updated clean up scripts (if necessary), descriptions of all configuration changes and additions, and test cases that the implementation team can use to verify tenant behavior we recommend that you create documentation such as a completed migration template, updated clean up scripts (if necessary), descriptions of all configuration changes and additions, and test cases you can use this information to verify tenant behavior the customer approves the configuration push from the uat instance of the tenant to the production instance of the tenant if the customer does not approve the configuration, resend the approval request if the customer does not approve the configuration the second time, work with the customer to resolve issues and validate the changes approve the configuration push from the uat instance of the tenant to the production instance of the tenant timing testing on the uat instance of the tenant typically takes two days step 6 after the customer has approved the migration and submitted the clean up scripts, remove any sample and test data that had been temporarily added to the staging instance of the tenant and then migrated to the uat instance of the tenant after you have approved the migration and submitted the clean up scripts, remove any sample and test data that had been temporarily added to the staging instance of the tenant and then migrated to the uat instance of the tenant push the uat instance of the tenant configuration (that is, the version 1 1 metadata and configuration data) to the production instance of the tenant this is a full metadata migration from the source to the target; that is, it is not a delta metadata migration timing because this step could result in a brief outage of the production instance of the tenant, we recommend that you schedule it to occur during a maintenance window (usually on a friday or weekend), unless the customer requests otherwise afterward the customer verifies that the production instance of the tenant is go live ready verify that the production instance of the tenant is go live ready request approval for the production instance of the tenant to go live if the customer does not approve the request, work with them to resolve any issues and approve the production tenant place the uat instance of the tenant in maintenance mode it is no longer available to the customer place the uat instance of the tenant in maintenance mode it is no longer available to you lock the production instance of the tenant copy the configuration for the new production instance of the tenant to the staging instance of the tenant while the staging instance of the tenant is still locked unlock the staging instance of the tenant from now on, the customer cannot use the staging instance of the tenant for further configuration without refreshing the production instance of the tenant refresh the staging instance of the tenant from the production instance of the tenant periodically to ensure that both tenant instances remain synchronized the customer can use the staging instance of the tenant for testing and debugging purposes unlock the staging instance of the tenant from now on, you cannot use the staging instance of the tenant for further configuration without refreshing the production instance of the tenant refresh the staging instance of the tenant from the production instance of the tenant periodically to ensure that both tenant instances remain synchronized you can use the staging instance of the tenant for testing and debugging purposes timing this activity typically takes three business days if a step fails step 4 if the metadata and configuration data migration from the staging instance of the tenant to the uat instance of the tenant in step 4 fails, work with the customer to do the following obtain a corrected patch on the staging instance of the tenant re initiate the process of migrating the metadata and configuration data from the staging instance of the tenant to the uat instance of the tenant step 6 if the metadata and configuration data migration from the uat instance of the tenant to the production instance of the tenant in step 6 fails roll back the changes (that is, the backup copy is restored) reinitiate the process of migrating the metadata and configuration data from the staging instance of the tenant to the uat instance of the tenant