ADMT provides three options on how to use it, where the first and maybe most used is the GUI:

It`s wizard driven and pretty straightforward to use.
The second option is the admt.exe command line utility:

In my opinion this is a pretty good example on how inconsistent various command line tools are compared to PowerShell. Although ADMT is a great tool, hopefully the next version will be rebuilt based on PowerShell.

The third option is scripting. There is a COM-object called ADMT.Migration, and there is a sample VB-script (templatescript.vbs) in the ADMT installation directory (by default C:\Windows\ADMT). This sample script is a good place to start to explore how the COM-object works.

Based on this I`ve written a sample PowerShell script, Invoke-ADMTUserMigration, to migrate user accounts and passwords using Windows PowerShell. This script uses the “ADMTDomain” option, which means that all users from the source OU will be migrated to the target OU. To see other available options, see the ADMT documentation and the sample VBScript. Migrating other objects, like groups and computers, the same way should be pretty easy when comparing Invoke-ADMTUserMigration to templatescript.vbs.

Note that since ADMT is a 32-bit application the script must be run from an x86 instance of Windows PowerShell. It also requires elevated privileges (Run as Administrator). Trying to run it in an x64-bit PowerShell instance or without elevated privileges will result in the following error:
New-Object : Retrieving the COM class factory for component with CLSID {285029CC-5048-4D90-8B38-22D304F513DC} failed du
e to the following error: 80040154.

Before trying to run the script I would recommend that you read the ADMT migration guide and ensures that migration works as expected by running a few test migrations from the GUI.

When this is done, I also would recommend to split the migration in batches as recommended in the migration guide. A maximum of 100 objects at a time might be appropriate. Before moving on to the next batch, check the migration logs (by default in C:\Windows\ADMT\Logs) to see that everything went OK before proceeding.

To take this a step further, I`ve created a function, Migrate-ADMTUser, that migrates a single user object. This would allow you to easily do things like this:
Get-ADUser -Filter {Company -like “Oslo”} | Migrate-ADMTUser

This example combines the Active Directory module for PowerShell with ADMT, allowing us to more fine grained control on what objects to migrate.
Note that both the sample script and sample function I`ve created is meant as a guidance on how to use PowerShell to automate ADMT. The optimal way as I see it would be creating an ADMT PowerShell module with functions for migrate other objects like computers and groups in addition to users and passwords.

Resources

ADMT 3.2: Common Installation Issues

ADMT Guide: Migrating and Restructuring Active Directory Domains (TechNet-version)

As described on the Migration Tools TechNet documentation, the following can be migrated using these tools:

Roles

Active Directory Domain Services and DNS
DHCP Server
File Services
Print Services

Features

BranchCache

Settings and Data

Data and Shares
IP Configuration
Local Users and Groups

Installation

Start by installing the Windows Server Migration Tools feature from the Add feature wizard in Server Manager on the destination server running Windows Server 2008 R2:

You can find the new feature on the Start-menu in Administrative tools:

After the “Windows Server Migration Tools” PowerShell prompt are opened, go to C:\Windows\System32\ServerMigrationTools.
Type SmigDeploy.exe /? to list the description and usage of this command.

Example usage

In this example we`ll migrate a DHCP Server running on a Windows Server 2003 machine. To create a deployment package for Windows Server 2003 32-bit, execute the following command:

When the package folder are successfully create, copy the folder to the source DHCP Server:

The only requirement on the source Windows Server 2003 server are Windows PowerShell (and thereby .NET Framework 2.0).

Start SmigDeploy.exe from the SMT_ws03_x86 folder to fire up Windows PowerShell with the Windows Server Migration Tools snapin.

Available cmdlets for this snapin:

Execute the cmdlet Get-SmigServerFeature to get the set of all Windows features that can be migrated from the local server:

The cmdlet returns the DHCP Server as a feature available for migration:

Here we got the DHCP Leases on the source DHCP Server, which are to be migrated to the Windows Server 2008 R2 server:

To export the DHCP Server configuration and database, run the Export-SmigServerSetting cmdlet with the following parameters (you will be prompted for a password to protect the exported file):

The export was successful, and we can see the exported *.mig-file:

Copy the *.mig file to the target DHCP Server.
To import the DHCP Server configuration and database, run the Import-SmigServerSetting cmdlet with the following parameters (you will be prompted for the password  for the exported file):

The DHCP Server feature was not installed on the Windows Server 2008 R2 server, but the Import-SmigServerSetting takes care of this automatically:

The import was successful:

After starting the DHCP Server service we can open the DHCP Server management console and verify that the migration was successful:

This concludes this post regarding the new Migration Tools, and I must say I really like this new feature, especially the fact that it`s leveraging Windows PowerShell. I would recommend you to play around with this in a lab environment to get to know it`s usage.

Update 25.08.2009: As stated in the documentation on Technet, the DHCP-service on the source server must be stopped (Stop-Service DHCPserver) prior to the export. Thanks to Max for pointing this out.
Update 15.01.2011: Note that the destination DHCP-server must be authorized. Thanks to Blazej for pointing this out.

1. If you move a mailbox from Exchange 2003 to Exchange 2003 or to Exchange 2007 RTM, you have to recreate the partnership manually.

2. If you move mailbox to Exchange 2007 SP1, there is no need to re-create the partnership manually.

3. Please note the certificate should be the same. Otherwise, you will encounter issues with certificate in Exchange ActiveSync.

For more information on how to re-create the partnership manually, see this article on the Exchange Team`s blog.

In previous versions of Microsoft Exchange Server, if you moved your mailbox to an upgraded server (such as Exchange Server 2003 to Exchange Server 2007 RTM) re-creating the partnership was required. However, if you move your mailbox to an Exchange Server 2007 with Service Pack 1, the new Sync State Upgrade feature is built into Move Mailbox and will allow you to continue synchronizing your device without resetting your partnership.

For more information on the Move-Mailbox cmdlet, see this article on TechNet.

In Exchange 2007 Service Pack 1 (SP1), if you move a mailbox to which a mobile device is synchronized using Exchange ActiveSync, the sync state of the mailbox is updated automatically during the move. You do not need to perform any additional steps, and the user does not need to again sync the device after a mailbox move.

Although you don’t move mailboxes, if you add a CAS server and users use the CAS server to maintain their Exchange ActiveSync access, you need to note the following:

In order for your users to continue to synchronize their mobile devices via Exchange ActiveSync with their mailboxes hosted on Exchange 2003 mailbox servers, you will need to ensure that Integrated Windows Authentication is enabled on all of the Exchange ActiveSync virtual directories (Microsoft-Server-ActiveSync) on Exchange 2003 mailbox servers.

For more information on how Exchange 2003 mailboxes are maintained after the Exchange 2007 CAS role are introduced in the environment, please see this article on the Exchange Team`s blog.