Using the Ivanti Neurons for ITSM Development Project

prior to release 2014, the only way that you could migrate data from one instance of a tenant to another was by using the operations console starting in 2014, you can use the development project to easily migrate data use the development project feature to create packages to migrate data from one instance of a tenant (such as staging) to another instance of a tenant (such as uat) you can also migrate data from one application to another using packages, you can pick and choose which data to migrate instead of migrating the entire application this feature allows to maintain a history of changes in metadata, validation data, configuration settings, and a few specific master data business objects it also allows you to package a unit of integral changes into a package for migration to another tenant instance if you have the operations console deployed in your environment, we highly recommend that you perform the migration there, between staging, uat, and production, instead of using the package import feature described later in this topic refer to the operations console guide for for additional information on this feature recommendations this feature gives you the ability to update the production instance of your tenant with configuration changes made in the staging instance of the tenant if these changes conflict in some way with your application, they cannot be undone occasionally, migrating data using the development project can take a long time and cause the application to time out the amount of time it takes to push a package depends on the number of transactions in the package, the amount of data in the tables, the number of indexes that are rebuilt, and more in general, a package under 5 mb takes less than 5 minutes to complete and a 20 mb package may take around 20 minutes if your package is larger than 20 mb, we recommend that you split it up into smaller packages to ensure that each smaller package completes the migration process and does not cause the application to time out we recommend that you plan and prepare for moving a package as described in this section we strongly encourage you to make a complete backup of the target tenant instance and to create a procedure for restoring the backup if need be if there is a problem with the uat instance of your tenant, you can restore it from the production instance of your tenant using the operations console, by refreshing the uat instance of your tenant if there is a problem with the production instance of your tenant, you need to restore the production instance of the tenant from the backup as quickly as possible using microsoft sql tools, as any transactions that are created in the production instance of the tenant after a backup and before a restore will be lost limitations the development project has not yet provided a way to validate package dependency you need to ensure that if you make a change that depends on another change, you migrate both changes before handing out a package for migration, determine whether the package is complete and self contained the package should contain all dependent changes not having all the required changes in the package may cause the application to fail when you migrate the package and you may have to restore the target application from the back up application you cannot use the development project and simple mode at the same time to use simple mode, you must disable the development project you cannot use the development project to migrate certain types of data for a list of the data that cannot be migrated, see the operations console guide for for additional information on this feature terminology the development project feature uses the following terms transaction an individual change to the database transaction set a group of transactions for more information refer to managing transaction sets docid\ ln ozq xpdwt0lookefwh project a group of transaction sets for more information refer to managing projects docid\ u q mi gxixybohlupj j package contains the transaction sets from multiple projects for more information refer to managing packages docid\ xfnoupmwh2dqnecimxo0a aspect information about a feature, a component, a patch, or even a configuration an aspect presence indicates the presence of the feature about using your named account to log in the first time that you log into the application as an administrator, the application displays a message stating that you are logging in as an administrator this is not suitable for making configuration changes if you make configuration changes while logged in as an administrator, you may not be able to package the changes properly we recommend that you no longer use a generic administrator account when you are in the configuration console with the development project, the application tracks all the changes made and attributes them to the user who made the changes if all users log in using the generic administrator account, there is no way to know who made the changes if you log into the application using the generic administrator account, the application displays a warning message if you see this message, click ok and then log out as an administrator and log back in using your named account about the metadata read only mode message when you use the operations console to migrate data, the production and uat instances of the tenant are always in metadata read only mode, which is equivalent to being locked, and the application displays a message stating that the configuration console is in production metadata read only mode when the application is locked, you cannot make changes to most types of metadata in the configuration console (you can only make changes to the following four items saved searches, reports, quick actions, and dashboards ) while migrating data, the application temporarily unlocks the metadata on the target application for cloud customers to unlock the application, create a service request with ivanti software, who can unlock the data temporarily for on premise customers to unlock the application, use the operations console see the operations console guide for for information on doing this about data validation when you export and import packages between tenant instances or different systems, it is possible that the target environment may not match the source environment for example, if the source environment includes a form called "incident 1" and the target environment also has a form called "incident 1", the migration process overwrites the source form with the target form this could cause problems if the forms were used for different purposes in earlier releases, implemented basic metadata validation before importing projects, such as checking the database schema and some business objects in release 2015 2, we extend the validation to include additional business objects such as forms, lists, layouts, quick actions, business rules, searches, indexes, counters, and pick lists in this release, in addition to checking metadata, we also check configuration data (also known as settings, which include things such as roles, workflows, and dashboards definitions) and some constraints this internal validation is done in memory the application applies the package to the target environment, but does not apply the changes to the database the changes are kept in memory and the application reviews the output the application displays warnings and errors so that you can see potential problems before importing the package you can only import the package if the validation returns no errors, although you can still import the package with warnings note that when you apply the package, there could still be validation errors even if the application does not show them these errors could come from the actual data in the database, from database connectivity, from database size, and so on about logs the frs ops change log business object stores historical changes in xml format for all metadata and settings, and for some data such as request offerings and authentication provider data you can view the list of changes in the transaction details workspace the frs ops metadata history business object has been deprecated, but remains a part of , as its data is still used in some workspaces it stores historical metadata changes in json format however, it does not contain the complete historical changes for all metadata you can archive the frs ops metadata history business object and delete the data once you do that, you will not see the change history of the deleted data you can also archive and delete the frs ops change log business object, but only if you will not use these changes in the packages once you do that, you cannot package or export the changes of the deleted table see archiving and deleting log data from the neurons for itsm databases docid\ tmpvz7tsfxzvjpswjr53c for more information about archiving data