The "swing migration" is typically done when upgrading one version of Windows Small Business Server (SBS) to another. You didn't mention SBS, and that migration method really isn't applicable in your situation.
You don't need a new domain to do what you're looking for. Hopefully you haven't gotten too far along with it and can start over, because you never want a multi-domain (or worse, multi-forest) Active Directory implementation if you can help it.
The migration from a single-server Exchange 2003 installation to Exchange 2010 is incredibly painless.
Join the server that will be hosting Exchange 2010 to your existing Active Directory domain as a member server. It's not recommended that Exchange be installed on a domain controller. I'll tell you that I've done it w/ Exchange 2007 before and it works fine, but it's not recommended and I've never tried it with Exchange 2010. If you want to make the E2K10 machine a domain controller, though, promote it now. (You really should have a dedicated machine to be a domain controller, and having at least two domain controllers is very helpful. You could continue to use the old server as a DC.)
Verify that your existing Exchange 2003 server has Service Pack 2 for Exchange 2003 installed. If it isn't, install it.
Install Exchange 2010 onto the new server. (Obviously, if you need to move your mailbox database or transaction logs to specific disks do that now before you start moving mailboxes over to the new machine.)
Read up on using mailbox move requests to move mailboxes from the Exchange 2003 Server to the new Exchange 2010 server. It's a very painless process, and there's no configuration changes that will need to be made on the user end.
After all the mailboxes are moved and the users have accessed their mailboxes at least once via Outlook you can begin the process of http://support.microsoft.com/kb/152959">retiring the Exchange 2003 server.
Internet email will continue to flow in and out of the organization via Exchange 2003. You'll want to transition your Internet email flow to the Exchange 2010 installation, though. That will involve creating a "Send Connector" on the Exchange 2010 side, an anonymous SMTP receive connector, and changing firewall rules to divert the mail flow.
You'll also want to be sure that you've got OWA on Exchange 2010 available if your users were using it. That will probably involve firewall rule changes.
Is your backup management software ready to support Exchange 2010? If not, think about that.
You may want to read up on Exchange Autodiscovery. It can have ramifications for your SSL certificate and DNS infrastructure, assuming you don't want to get little annoying warnings from Outlook. Have a look at these for some good background (the second refers to Exchange 2007, but it hasn't change dramatically in Exchange 2010).
You'll definitely want to review Microsoft's documentation on upgrading and coexisting. I'm leaving a lot of little details out, but it's really a pretty painless process.
We did this successfully by using these instructions:
I've found a slightly more elegant solution to this problem rather
than just aggressively killing the process until Windows gives up
trying to start it again, and I'd like to share it in the hope that
Google will re-index and pick it up for others to use. You may have
noticed this service cannot be disabled via the MMC snap-in.
My search term on google was: how to stop the SBCore service. Anyway,
down to business…
As you probably know, you have a service called SBCore or "SBS Core
Services", which executes the following process:
C:\WINDOWS\system32\sbscrexe.exe. If you kill it, it just restarts –
and if you try and stop it you are told Access Denied.
If you fire up Process Explorer, you can select the process and
Suspend it, now we can start to disable the thing. Run regedit and
expand the nodes until you reach the following hive
/key:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SBCore Right
click this, hit permissions and give the "Administrators" group on the
local machine full access ( don't forget to replace permissions on
child nodes ). F5 in regedit and you'll see all of the values and data
under this key.
Select the "Start" DWORD and change it from 2 to 4 – this basically
sets the service to the "Disabled" state as far as the MMC services
snap-in (and windows for that matter) is concerned.
Next, adjust the permissions on the file
C:\WINDOWS\system32\sbscrexe.exe so that EVERYONE account is denied
any sort of access to this file. Then go back to process explorer, and
kill the sbscrexe.exe process, if it doesn't restart –
congratulations!
Load up the services MMC snap-in and you should find that "SBS Core
Services" is stopped and marked as Disabled.
Note that doing this may put you in violation of the EULA. We did it because the migration did not get a chance to finish before I went on holidays; this tied the company over until after I got back and could finish the job.
Best Answer
You have some misconceptions here. I'll try to answer your questions while dealing with those:
SBS does not and never has limited you to a single domain controller. It limits you to a single copy of SBS being run on the network. While you are migrating, it allows you to have both of the SBS servers on the same network. After 21 days, your old SBS server will start shutting down every 1-2 hours. The 21 days allow you to do the migration at your old pace. The old server will still function properly, it is up to you to migrate roles like DHCP over to the new server when you are ready.
The standard SBS migration process involves some downtime. You may schedule certain things to occur during off business hours (like Exchange migration and file server migration). Your other alternative is to use a different migration method. There's the swing method available at sbsmigration.com or the zero downtime method available at zerodowntimemigration.com. Both of those methods should provide for considerably less downtime. Both methods do cost some $$$ though
There is no such thing as a primary domian controller. Those things went away with the introduction of Active Directory. We now have a multiple master setup. During the migration, your new SBS server will become an additional domain controller and all FSMO roles will be transferred to it. For more information, read up at Technet.