Example: Migrating Request Offering Changes By Enabling the Ivanti Service Manager Development Project

this example is an end to end example of migrating request offering changes by enabling using the ivanti service manager development project it describes how to make a change to a request offering in the staging instance of a tenant and then migrate the change to the production instance of the tenant in this example, the ivanti service manager development project is enabled and data is migrated by both applying a package and by using the push link this example is copied directly from the ivanti service manager online help about this example docid\ otbpw2k5ppaxejsiiv whbefore you begin docid\ otbpw2k5ppaxejsiiv whpackaging the changes using ivanti service manager docid\ otbpw2k5ppaxejsiiv whmigrating the data from the staging instance to the uat instance docid\ otbpw2k5ppaxejsiiv whmaking changes to the request offering in the configuration console docid\ otbpw2k5ppaxejsiiv whtesting the change docid\ otbpw2k5ppaxejsiiv whmigrating the data from the staging instance to the production instance docid\ otbpw2k5ppaxejsiiv whmigrating the service request data from the uat instance to the production instance docid\ otbpw2k5ppaxejsiiv wh about this example ivanti service manager does not have a system for tracking request offerings, so to migrate a request offering from one environment to another, you must create and apply a package and also do a master data push using the operations console creating and applying a package alone does not migrate the request offering change before you begin before you begin, use the operations console to refresh the staging instance of the tenant from the production instance of the tenant this ensures that you have the same baseline in both environments before you make the change packaging the changes using ivanti service manager when you make changes to request offerings, ivanti service manager tracks the changes made to the request offering and associated workflows and quick actions, but does not track the changes made to some related content ivanti service manager does not record changes for the organizational unit, configuration item service, location, or request offering links to organizational units, configuration item services, or locations this can cause confusion when you move changes from one system to another the changes that the system records may differ depending on if you are logged in as an administrator or as another role when you make the changes if you make the changes as a service owner, you cannot select the project to apply the changes to therefore, all changes are added to the default project if you make the changes as an administrator, you can select the project to apply the changes to before you make the changes to the request offering, we recommend that you create a new project and apply the changes to that project see creating a project docid\ oazckiixxshugjnkpasik (optional for administrators only ) go to the configuration console, create a project, and then select it make the changes to the request offering the system tracks the changes to the workflows and quick actions associated with the request offering create a package with the transaction sets associated with the changes that you made to the request offering ensure that the package contains all of the changes made to the system since you made the baseline, as described in before you begin docid\ otbpw2k5ppaxejsiiv wh , regardless of if they are related to your project migrating the data from the staging instance to the uat instance log into the operations console refresh the uat instance of the tenant from the production instance of the tenant from the tenants tab, find the instance to migrate and click manage migration at the top of the page, click enable to enable the ivanti service manager development project at the confirmation message, click ok in the arrow going from the staging instance of the tenant to the uat instance of the tenant, click apply package do the following in the source package field, select the package to migrate check skip target tenant backup select apply without validation this allows you to apply the package even if there are errors you may need to fix the errors after the change is applied, if you do not want to restore the database and fix the root cause click execute the system migrates the package in the arrow going from the staging instance of the tenant to the uat instance of the tenant, click push do the following in the operation field, select copy master data only check delete data items in uat that do not exist in staging check service request click execute the system migrates all of the service requests making changes to the request offering in the configuration console if the target tenant instance does not have an equivalent request offering, (for example, if you are importing a package from the app store or a package from another system), you must manually link the configuration item service, organizational unit, and location log into the service desk console on the uat instance of the tenant open the request offering workspace find and open the existing request offering on the 1 define request offering page, for the service field, select the configuration item service associated with this request offering note that in many cases, the configuration item service is represented by a guid and not by its name in the drop down list be sure to select the correct configuration item service click next twice until you reach the 4 publish action access page click add to add a new organizational unit and location the system displays a new line click any under the team header and select the organizational unit associated with this request offering click ok note that in many cases, the organizational unit is represented by a guid and not by its name in the drop down list be sure to select the correct organizational unit click any under the location header and select the location associated with this request offering click ok note that in many cases, the location is represented by a guid and not by its name in the drop down list be sure to select the correct location click save & exit testing the change log into the uat instance of the tenant and test the changes if anything is wrong, perform the procedures in both packaging the changes using ivanti service manager docid\ otbpw2k5ppaxejsiiv wh and migrating the data from the staging instance to the uat instance docid\ otbpw2k5ppaxejsiiv wh when you are finished testing the change and are satisfied with the results, go back to the staging instance of the tenant and close the package this ensures that no further changes in the system are added to the package migrating the data from the staging instance to the production instance log into the operations console from the tenants tab, find the instance to migrate and click manage migration at the top of the page, click enable to enable the ivanti service manager development project at the confirmation message, click ok in the arrow going from the staging instance of the tenant to the production instance of the tenant, click apply package do the following in the source package field, select the package to migrate ensure that skip target tenant backup is not checked select apply without validation this allows you to apply the package even if there are errors you may need to fix the errors after the change is applied, if you do not want to restore the database and fix the root cause click execute the system migrates the package migrating the service request data from the uat instance to the production instance you must publish the service request master data from the uat instance of the tenant to the production instance of the tenant because the uat instance has the tested service request data (if you are sure that no changes were made to the staging instance of the tenant, you can push the service request data from there to the production instance of the tenant instead ) log into the operations console from the tenants tab, find the instance to migrate and click manage migration in the arrow going from the uat instance of the tenant to the production instance of the tenant, click push if there is no push link in the arrow, you must push the data from the staging instance to the uat instance in the operation field, select no op (increase version only) and click execute do the following in the operation field, select copy master data only in the additional data section, select any or all of service (ci service), organizational unit (organizationalunit), and location (location) check skip target tenant backup before operation check delete data items in production that do not exist in uat click execute the system migrates all of the service requests