Performing a configuration migration is pretty straight forward. You just have to pay attention to some things. Besides the excellent guide (Configuration Migration Deployment Guide ) I also pay attention to the following points:

1. FIM MA health

This is a rather nasty one. However if you fail to detect it, and you happen to migrate your configuration to a FIM MA in this situation you’ll be doomed to a do a rollback using SQL backup-restore. The good news it’s easy to detect. Every time you perform modifications to your MA’s or MV configuration, this info get’s replicated to the FIM Service. You can see this info below administration > all resources:

Every time such an update occurs, requests are logged in the FIM requests log:

That’s also one of the reason why running a Full Synchronization profile on your FIM MA very often is a bad idea. This data gets replicated to the FIM Service every time you do a full sync on your FIM MA. This is the easiest way to make your FIM Service DB explode in size. But, back on track now. Using the following WMI trickery (discovered by Craig Martin): MSDN: MIIS_ManagementAgent Class

You can force this replication to occur by executing the following statements:

### Get the FIM MA
$fimMa = Get-WmiObject -Class MIIS_ManagementAgent -Namespace root/MicrosoftIdentityIntegrationServer -Filter ("Type='Forefront Identity Management (FIM)'")
### Call the WMI method to ReSync the Config Objects from miiserver.exe to microsoft.resourcemanagement.service.exe$fimMa.ResyncSyncConfigObjects()
$fimMa.ResyncSyncConfigObjects()

Now what should the outcome look like?

The ReturnValue Success is a good start. You also should see the requests being logged. However, if you see the following entry in your application log you got some work to do:

In words:

A update on the configuration of a MA or MV failed to replicate to a target connector directory that is capable  of storing MA/MV configurations.  As a result, the MA/MV configuration data in this connector directory is not up to date.  Please correct the condition that causes the error, and triggers a resync by updating the password information of the target MA.
Additional information:
Error Code: 0x80230709
Error Message: (The extension operation aborted due to an internal error in FIM Synchronization Service.)
Operation: Clean up MAs
Name of the MA to replicate: 
Guid of the MA to replicate: 
Name of the target MA: FIM MA
Guid of the target MA: {35F6A1E2-CCF6-4C8A-91FF-2114625B144D}

I haven’t found a nice workaround just yet… What I’ve done successfully in the past:

1. delete the FIM MA (CS and MA itself)
2. wipe the MV
3. Reconfigure the FIM MA from scratch or by importing an earlier (healthy?) FIM MA xml.
4. Import, join and sync in the proper order

This might seem like a lot of pain, and it sure it. But I prefer avoiding even worse: having a setup which refuses to recognize it’s declarative SR’s.

2. MA Schema Up-to-dateness

Very short tip: before you start exporting/importing, make sure your schema’s of your MA’s are up to date. Doing an update schema on each MA is a quick & easy test. This way you can avoid some additional trickery. It shouldn’t break anything, but it might give you all sorts of weird issues.

3. Attribute Precedence

Make sure to double check your attribute precedence. If you have declarative rules and classic rules (which the FIM MA always does), you might have to toy around with the attribute precedence. As this might get scrambled due to the order the MV gets the contribution info.