While recently working with FIM, I found that we were able to remove a declarative rule from use as the attribute flows defined were no longer required. The process for removing the ERE’s is well defined in that you can simply create a transition in MPR that goes against the set of objects that the ERE is being removed from (which of course, calls the workflow that actually creates the “Remove” ERE).
So now in the Portal you have an “Add” and “Remove” ERE. The synchronization engine then processes the remove and stages the deletions of the two EREs from the FIM Service. Think about how many objects this operates against.
If you’re working with 200 objects, that’s great, its 400 exported deletions but start thinking the large enterprise with say 100,000 objects that have the “Remove” ERE applied and how long that will take to process in your environment.
I would strongly suggest reviewing the overall system performance when it comes to operations of this type. Perhaps even scoping the task to take the synchronization rule out in phases, if an algorithm for the criteria based set can be properly defined. Remember that classic rules are executed last so you can “override” the flows that are being done by the declarative rule you’re phasing out (even if that means writing a simple extension that copies the current value of the csentry back into itself which causes no net change but prevents the particular attribute flow in the removed synchronization rule from having any net effect).