When moving a FSMO from one DC to another DC you have two possibilities... transfering and seizing

You transfer a FSMO role when both the source DC as the target DC is up and running. There is no need to worry about the exchange of information concerning the FSMO role as that will happen automagically!

You seize a FSMO role when the source DC is not available anymore and the target DC is up and running (of course!).

If the source DC is not available temporarily and will come back online within an acceptable timeframe DO NOT SEIZE the FSMO role! If you DO SEIZE the FSMO role the original FSMO role owner must never come back online again and needs to be removed from AD. For information on how to cleanup AD metadata see: http://blogs.dirteam.com/blogs/jorge/archive/2005/12/03/213.aspx

When seizing a role to another DC, there is no exchange of information because the source DC is not available. Because of that you also might wonder which DC at that moment is the best candidate to become the new FSMO role owner. To answer that question the procedure is the same but it depends on what FSMO role is being seized. Make sure you only cleanup the AD metadata of the DC that died after using the command, or you are looking at some GUID instead of a server name.

To determine the best candidate to seize the FSMO role(s) to, run the following repadmin (w2k3 version) command on some DC and see which DC in the list has the HIGHEST USN for the DC with the FSMO role that died:
If it concerns the Schema Master FSMO use for <NC>: CN=schema,CN=configuration,DC=<DOMAIN>,DC=<TLD>
If it concerns the Domain Naming Master FSMO use for <NC>: CN=configuration,DC=<DOMAIN>,DC=<TLD>
If it concerns the PDC/RID?Infra Master FSMO use for <NC>: DC=<DOMAIN>,DC=<TLD>

For [DC_LIST] see the following:

#########################################################

This section explains the syntax of the semi-global dc_list parameter

{dc_name dc_name.. | * |partial_server_name*| site:site_name |gc: |fsmo_type:[name]}

dc_name dc_name ...

Specifies the host name of a domain controller, or a list of domain controllers separated by a space.

*

Standard wildcard character. When this is used it returns all domain controllers in the enterprise. Improper use can cause a significant increase in network traffic.

partial_server_name*

Partial wildcard character matching. For example, if given the partial domain controller name "woodgrovebank*", the wildcard character would pick up woodgrovebank-dc1 and woodgrovebank-dc2.

site:site_name

The site: parameter takes the name of an Active Directory site (site_name), and returns all domain controllers in that site.

#########################################################

--> REPADMIN /SHOWUTDVEC [DC_LIST] <NC>

As you may also know the PDC FSMO in the forest root domain could be configured to sync time with an external time source or to sync with its own internal hardware clock. So when seizing or transfering that FSMO role the time sync configured is NOT MOVED! For that you need to configure the new PDC FSMO role owner accordingly, and if the source owner is still up and running you need to remove the time sync configuration. More information on how to do that can be found at: http://blogs.dirteam.com/blogs/jorge/archive/2005/11/20/111.aspx

ADDITIONAL INFORMATION WHEN (FORCE) DEMOTING A DC THAT HOLDS FSMO ROLES:

* When demoting a DC that owns FSMO roles, the FSMO roles will be transfered automatically to another DC that is available to prevent orphaning. However, the choice of a new FSMO roles will be random. Most of the times it will be a neighboring DC. If you have more than one neighboring DC, you still do not know which one was chosen! It is therefore a best practice to FIRST transfer the FSMO roles to a target DC you want, before demoting the source DC.

* When force demoting a DC that owns FSMO roles, the FSMO roles will be orphaned. Be aware of that. W2K3SP1 DCs will warn you if you are force demoting a DC that owns FSMO roles for each FSMO role hosted on that DC