Depending on the connected systems, you will need to decide how to proceed. Each user in the system will require an appropriate DirXML-Association, one per driver.

Some are easy to 'make' by hand, once you understand what the DirXML-Association value ought to be, check out this article to get a feel for what the various values ought to be:
www.novell.com/.../open-call-idm-association-values-edirectory-objects

For example, at a client with 1.5 million objects, we added a new driver for 600,000 of them. Rather than let the engine try to process 600K, we actually scripted retrieving the GUIDs processing them, and then using an LDIF to write the values to the Identity Vault.

If you 'only' have 10,000, it is not so bad. You should realize if you migrate a user in one system, odds are good you will cause enough of an event to cause all the other drivers to fire. In which case you might want to think about it carefully in terms of overall processing.

When you Migrate from Identity Vault, you select a list of users, and iManager basically writes a DirXML-Association to the object with a state of 4 (0 is ignore, 1 is associated, 4 is migrate, 3, 5, 6 and the rest of the way to 2^32 are not really used) which causes an event that generates a event for the object.

If you migrate FROM application in iManager, the engine submits a query (query-ex if the driver supports it, and thus pages to the ECV controlled default) and the doc that is returned is the list of objects to .

You can use DXCMD and there is a option to Submit a Command, and you provide the file name to the XDS doc with the query you need and it will process it as if you did it in iManager. So you can have a little better control than iManager allows, but it has to be valid XDS query of course.