Directory Synchronization vs. Migration

Though it can be used to bulk load objects into a target domain, the directory synchronization is (practically speaking) primarily for keeping users' passwords and group memberships up to date between source and target before you cut your users over.  It can also help to make sure that any net new objects created in the source during the migration, get created in the target.

If you use it for bulk loading objects into a target domain you cannot:

Be selective about where (what Target OUs) the objects are created in.  With a migration session, each batch of objects can be created in a different target OU.

You cannot perform "transformations" on the objects when they are re-created in the target - for example, applying a new naming convention for samaccountnames.

Hope this helps.

Though it can be used to bulk load objects into a target domain, the directory synchronization is (practically speaking) primarily for keeping users' passwords and group memberships up to date between source and target before you cut your users over.  It can also help to make sure that any net new objects created in the source during the migration, get created in the target.

If you use it for bulk loading objects into a target domain you cannot:

Be selective about where (what Target OUs) the objects are created in.  With a migration session, each batch of objects can be created in a different target OU.

You cannot perform "transformations" on the objects when they are re-created in the target - for example, applying a new naming convention for samaccountnames.

Hope this helps.

In short, a migration session can only add objects and attributes while you wait. A Sync session can create objects, deleted objects, write attributes and delete attributes. 

The "while you wait" part that Jeff mentions is an important detail.

Migration sessions are launched by a user.  Directory synchronization runs on its own schedule on a continuous start/stop basis.

The use of one approach or the other is contingent on a number of factors that contribute to your process design.  They are not mutually exclusive either.

Another tidbit is that migration sessions can be undone while directory synchronization can not.   

Good point!   This is why I sometimes refer to the directory synchronization approach as an "object pump".

A Migration session can do the following

1. Recreate the source OU structure in the target, the sync can only create objects in a single selected OU or container
2. Using an Import file, the source attribute values can be overridden via an import file
3. Reconnect the Exchange mailbox in an intra-forest migration
4. Add source members to the target migrated domain local groups. 
5. Set the password to the username with prefix/suffix
6. Set the password to a fixed value
7. Set the password to a random value
8. Each object can be "Undone" as needed. 

The Directory Sync can do the following

1. Objects removed from Group Membership 
2. Values removed from other attributes
3. Objects deleted in the target when deleted in the source

Both processes are actually handled by the Directory Sync agent. When the sync is enabled, a full sync session is run, everything in scope if read and written to the target. It takes as long as it takes to process. When it is complete, it will sleep for 15min (default) and wake up. When it wakes it will query the DC for the all replication messages higher then USN X. If the object and attribute is in scope, it will be applied, if not it will discard. If the Target DC is change (though election) it will automatically run another full sync.