So SBS 2011 will be RTMing soon and your first migration should be your own, or a test one.
So how do you do a test migation?
You need a HyperV play box. Buy a server, buy an overgrown desktop, buy SOMETHING that holds at LEAST 8 gigs, preferably more. Now add a big hunking hard drive. Go to your action pack licenses and install the Server 2008 r2 license.
Okay now to set up the box for HyperV
Once the server is set up you need to install the HyperV role. The server can (and should) stay as a workgroup as more often than not in your SMB clients that's how you'll be installing the HyperV parent. Launch the Server roles wizard and add the HyperV role. Limiting yourself to just the HyperV role and the minimal roles needed for management is key to ensure that you have less to patch and stay within the 1+1 licensing.
Once you add the role, you are now ready to set up your networking.
In a production machine they recommend one nic reserved for management, one nic reserved for the operating system. If you are doing a test box, you don't have to be quite so "best practice". A single nic with both you going through RDP and the HyperV servers underneath going through the same nic will work fine.
In the Actions menu on the right hand side you set up your Virtual network settings.
Word of advice here. Do wired. I tried to to a wireless binding in Hyper V. While it works when you are at the physical machine (say a laptop) where you can bind the service from the wireless nic over to the HyperV network by installing the Windows Desktop Experience service as that adds the wireless management ability, you cannot then RDP into the wireless connection once you bind the wireless nic to the virtual network. I tried everything and the minute you bind the two you lose RDP. So just plan on a wired connection as it will make your life easier to rdp into the box.
Also plan on having some sort of router in front of that machine so that you can enable/disable DHCP at will. You can even put a virtual router in your Hyper V (ipcop for example). Since I use a box with low RAM memory I turn on and off virtual machines when I need them. Thus the need for a router so that you can turn on DHCP (for Aurora) and turn it off (for SBSv7).
To set up a virtual nic that talks to the real external nic and thus your HyperV guests can act and talk just like real computers, go into the Virtual network setup. Click on New virtual network and make it an external network.
Bind the connection to the nic that has an active live Internet connection
Ensure that the "allow management operating system to share this network adapter" is checked. Click OK.
You will now note that you have two network connections in your network settings. The REAL nic now only has a binding to the virtual network bus, the virtual nic now has the IPv4 settings and what not. This part is probably the biggest thing in networking to get your head around is how the nics look in HyperV.
So when you build any computer, ensure that it has this external nic as it's nic in the hyperv settings. It doesn't matter if you have two or three machines sharing this nic card (at least in terms of testing). In the real world you'd probably have a quad card and have various machines connected to various nic slots.
So now you need a test SBS 2003 box as your 'dry run' box to test with. This is true for both the Microsoft migration method and the Swing migration method. I'd strongly advise that your first migration not be a client box, but be a test one.
So how do you make a test box? Storagecraft for one. http://technet.microsoft.com/en-us/sysinternals/ee656415.aspx Disk2vhd for another perfect solution. If you are doing it just for test, you can to Disk2vhd on a live working server, preferably afterhours as it uses the vss backup ability to make a vhd. If you want a more real world migration, temporarly shut down any SQL or Exchange service. I make the vhds save to an external usb hard drive.
Then literally copy the VHDs you made to the HyperV server and set up the drives exactly as the VHD (hard drives) were in the server you pulled the virtual from. Now boot the box. You'll find it will boot just fine but will have three issues:
1. You need to remove the ghost nics of the original physical box. (see past post on this topic -- http://msmvps.com/blogs/bradley/archive/2009/11/04/p-to-ving-with-the-sysinternals-tool.aspx)
2. It will need to reactivate. Dig up your license number and key it in. It will not in any way shape or form harm/mangle/impact the license of the working box. While you can let it run like that for three days, to properly test migration you need to activate it.
3. You'll need to run the ceicw to redo the networking.
Now you have a running box in a HyperV that is a fully functioning replica of your real server. So make sure this never gets near your existing network (ergo why you want your HyperV test box behind a router so it can't talk across the networking cable to your other SBS server. It has the exact same name/dns/sid/you name it as your real box and you will really mangle the brains (and kerberos) of your existing workstations if you introduce the cloned server in your existing active directory. Also keep in mind that while I have no issues saying "go ahead make snapshots with your HyperV test" that's only because it is a TEST. You never ever ever want to do snapshots on a Domain controller. (If you want to get more into the details of why you need to be careful with cloning and virtualization in a HyperV network check out http://www.msteched.com/2010/Europe/SIA320 )
So now you have a replica to begin the process of building up your migration process. Not to mention taking a replica of your existing SBS 2003 means you can keep a copy as a base and then practice both the migration from SBS 2003 to SBS 2011 but also the needed tasks you'll be doing to go from SBS 2003 to Aurora.
Next up, doing a bit of pre-migratin' homework (running the bpa and what not) to ensure you are ready to go.