2 of 2 people found this helpful
Using AST:LoadAttributes is definitely the recommended way to achieve this. All the workflow to make this hang together is now built into the process, so you will find this more robust.
One other observation. Re-using the recon.ids from V7 may not be such a great idea. Generally these GUID type identifiers which the system generates , are only guaranteed to be unique within an AR Server instance. So it is possible (probably remotely) that you may generate a recon.id in V9 that duplicates one brought across from V7. I know this is a pain, given the alternative is to run a somewhat redundant ID activity using the recon. engine, but will keep it clean.
For the reconciliation comment, you mean CMDB keeps a running list of reconciliation identities? I had though recon id is unique by data set and enforced at some level.
To some clarity, we are migrating from a well used v7 instance to an empty v9 instance. I didn't expect any issues with bringing over recon id to make merging and carrying over other data like asset people etc... easier. I was/am hoping to avoid writing recon rules for my v7 data.
Sorry for delay - been travelling a bit.
Re recon. ids - no the CMDB doesn't keep a running list as such, whenever a new recon. id is needed it uses some algorithm to generate it - and that algorithm uses some local AR server attributes to generate the RE ID. I am saying that by copying RE IDs from V7, instead of letting the V9 Recon process generate them as part of the migration, then you have a small risk of duplication. The cleanest approach would be to move the V7 data to a staging dataset in the V9 environment, with RE IDs set to 0, then run a recon job to ID them and merge to golden dataset. End result is the same but there is no risk of dupe recon. ids being created.
If you haven't seen any issues to date, then perhaps you can relax and just take this as something to keep in the back of your mind (and avoid writing RE jobs etc for all of this)