Migration manager is a really great tool for migrating configurations from one Maximo instance to another. It does all the validations and tells you of any dependency that you may have missed in the package. Unfortunately it doesn\u2019t tell you that while creating the package but does it while the package is being deployed and I wouldn\u2019t blame migration manager for that. When the package is being created in the source environment, it doesn\u2019t really know where it\u2019s going to be deployed and whether the target environment had all dependencies or not. It\u2019s when the package is being deployed that the migration manager gets to know that the dependencies don\u2019t exist in the target environment and the package errors out. I\u2019ll take an example and explain.<\/p>\n

Let say you want to migrate an object from one environment to another. You create a migration manager package for that object which includes all its attributes but not the domains that are associated with those attributes. When you deploy this package to the target environment, it would fail if those domains don\u2019t exist there.<\/p>\n

Migration Manager has its own section for mentioning dependencies and most the out of the box migration groups have dependencies already specified.<\/p>\n

<\/p>\n

<\/p>\n

But I don\u2019t prefer using this dependency functionality of Maximo and here\u2019s why \u2013 If you see the images above, Data Dictionary is one of the dependencies for the application migration group which should be the case but what this would do is take the entire data dictionary from the source environment and deploy it in the target environment.<\/p>\n

You really wouldn\u2019t want to do that because<\/p>\n

\n
1. If a developer has created any attribute or domain for testing some functionality and didn\u2019t delete those, they would be migrated too. Worst, if someone changed or removed a class from an OOB attribute or removed the domain associated to it, that would be migrated too. This could break existing functionality.<\/li>\n
2. And if not any of that, it would unnecessarily take a lot of time for deploying the package since there would be the entire data dictionary from the source that would have to be compared to the existing data dictionary of the target for changes.<\/li>\n<\/ol>\n

   Unfortunately if you don’t know about this feature of Migration Manager or you are not careful about it, you might unknowingly migrate certain configuration that were not required.<\/p>\n

   So it\u2019s better to maintain dependencies by you yourself then having Maximo maintain it for you.<\/p>\n

   Have a great day!<\/p>\n

   Cheers!<\/p>\n","protected":false},"excerpt":{"rendered":"

   Migration manager is a really great tool for migrating configurations from one Maximo instance to another. It does all the validations and tells you of any dependency that you may have missed in the package. Unfortunately it doesn\u2019t tell you that while creating the package but does it while the package is being deployed and … Continue reading Things You Must Know Before Using Migration Manager<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[15],"tags":[],"yoast_head":"\n