I recently have posted some documents about how to use and deploy objects using ‘Ready to Migrate’ and a ‘Release’ and some of you may be asking what the differences are between the two. Essentially, they accomplish the same thing but there are differences in how they can be used. Below I will describe the similarities and differences between them and you can determine which one will work best for you.
1. Both can associate multiple archive sets from multiple CSRs and developers in order to do one single mass migration.
2. Both utilize approvals and workflows to ensure that no objects are migrated pre-maturely.
3. Both can be migrated using the ‘Mass Migration Wizard.’
4. Both can be reported on as ‘unique’ entities (Objects Ready for Migration and Release Mgmt – Archive Sets by Release.
5. Both can only be done by authorized personnel that have security rights and access to the target environment.
1. Ready to Migrate uses a check box while a Release using a drop down in the archive set ‘Details’ screen.
2. Ready to Migrate is used once after which the target environment to which it was deployed is unchecked. A Release will keep the association and can be used to the same environment multiple times without having to check a box again.
3. Releases can also be done using the ‘Archive sets – Ready to Migrate’ wizard
4. Releases have a ‘Release Recovery Wizard’ whereas ‘Ready to Migrate’ recovery needs to be done in the respective CSR’s.
5. Each ‘Release’ needs to be created before objects can be associated with it.
As you can see, while they both accomplish the same end result they have distinct advantages. I believe ‘Releases’ offer an advantage when migrating archive sets back into an environment that may be refreshed frequently and therefore the association is static. An example would be if you have scripts you like to deploy after each refresh to clean data, reset passwords, etc. a release offers you the ability to do deploy those consistently and without making a re-association with the target. Ready to Migrate helps ensure objects are not re-migrated to a target environment more than once unless implicitly instructed to do so. What your needs are sand internal policies are should determine which is the better fit for you.