sbs 2003 migration to sbs 2008.

You are better to run the migration as in the MS set out in their guides. The simple basic steps are:

Install 2008 in migration mode
This will then join the existing domain, transfer the FSMO's to the new server, allowing 3 weeks before your old server shuts down.
you then use the wizards to migrate Mailboxes over to the new server (out of hours is best then you can just have users sign on to the new server when they come in)
Then move shares etc using robo copy (to keep NTFS permissions)
Then move printers
Then you can sadly decommission the server after the 21 days

You wont be able to do what you asked in Q1 because Active directory works with SIDs not names, therefor by doing it this way you will have to rebuild your whole domain.

Q2 Use the MS migration way.. its much easier, but you can use exmerge to extract PST data under 2Gb.

Q3 you will have to set them all up again, because even if the name is the same, all the SIDs and other importan data is different to the PCs/Server.

The best method I have found and have used successfully for 5 years and atleast 25 migration projects is the 'swing migration method'.  http://www.sbsmigration.com/

You dont need to use Swing Migrations anymore unless you using the same Hardware, Microsoft have provided a solid Migration path for 2003-2008

to clarify the answer to Q3, once you set them up again, they will be invalid on the new server.  The computer can only be a member of 1 domain at a time.  Even though the domain name may be the same, the SIDs won't match up.  If you want to keep the same server name, the swing migration is pretty much the only way to go.

I meant to say they will be invalid on the old server.

The purpose of a swing migration, other than using the same hardware, is using the same server name.  If that is important (it sounds to me like it is for testing purposes) then the swing migration method is still very relevant.

First question - If I leave the domain name and ip address of the new server the same as the old one then I guess that I can power of the new and power on the old server anytime - In other words I can work on the new server outside of hours and put the old one back up in time for production.
===
While technically true, you will have problems with the old server. Servers expect to run 24 hours a day and there are many scheduled events that performing tuning, maintenance, and reporting in the background. If you want to configure a new server, do so on a seperate VLAN or LAN, not on your production network, and not by taking down your production system.
===

Second question - When the new server gos live I wil need to migrate the exchange mailboxes and calenders across from the old one - can you advise on the best way to do this.
  We only have six users , I was thinking that I might just export the calenders and mail (.psts) on each client PC, and then just reimport them when the new server is active.
===
Exporting and importing will be the ONLY way to do this if you choose not to use the migration process.
===

Third - If I use the same domain name and users then I expect the client PCs to connect without problems, or do I need to set up the users again on the clients.

===
user accounts will have to be created, their data copied, and new permissions set on *every* folder and every file. Internally usernames don't matter to windows. Each account is assigned a very long number (usually represented in hexadecimal) called a Security ID (or SID) and each account is unique. Creating a new account with the same name will still result in a different SID and thus access to existing files, servers, and serviecs will be denied.
That also means that client machines will need to be removed form the old domain and joined to the new (computer accounts have SIDs too and the new server will be unaware of the computers and thus will block them from connecting to the new network for such things as group policy and Active Directory, essential for any domain-based network.)
In other words, you'll be migrating either way. The only question is would you rather o so manually and through a lot of pain, or would you rather use a documented process and have an infrastructure of other people that have done so to rely upon for advice?
The MS method is good, as is a Swing Migration kit, as mentioned in another post. Either method, however, is better than winging it solo (in my not-so-humble opinion.)
-Cliff
 

I must agree with Dave_AND.
Question1: No. User created in old domain will have different SID like "same" user created in new domain. Even if you use ADMT to export end import users form old to new domain they won't have the same SID. But there will be connection to old users via SIDhistory.
Question2: You can do it your way. Dave_AND covered other possibilities.
Question3: It is not problem setting up users, but exporting and reimporting user profiles.

As you have such a small number of users you can take both ways. If you have problems with old server I would go with fresh install and manually move all data. If your old server is functioning properly I would go for migration path.
Anyway you should have a working backup (and also even better old server disk images). The two servers can coexists for several days with no user downtimes, so at migration you don't need to have hurry.
I have done several sbs2003 to sbs2008 migrations using Ms procedure without a problem.
But I would recommend - if you get some errors especially migrating exchange server, take your time and make sure that exchange is migrated properly. If you will ignore that errors and you will not give exchange server enough time to migrate (public folders migration could take two-three days even if "empty") you could get in trouble.

@cgaliher:
At answering first question you forgot the most important reason you have covered in answer to Q3 ;)
Computers in new domain will not be trusted.

As a point of clarification, I do not agree with the statement that there is no need for a swing migration in the 2008 era where MS has documented its own process. And not just because of same hardware or same server name.
While not an endorsement of one over the other, a swing migration takes a migration approach that is different than the MS guide on a very fundamental level. It uses a documented methodology of *seizing* DC roles and performing a configuration that is almost completely offline. This allows for some significant benefits over the MS method that, by its design, requires both servers to be online and a constant stream of data shuffling between the two.
Some of the benefits of an offline configuration involve recovering from failure (the active server was not exposed to the failure, unlike the MS process) and more time to configure and test if necessary (unlike the MS method involving the 21-day limit.)
Now these benefits are important to some organizations, and not to others. There are also some places where the overhead of configuring a swing migration doesn't make sense, particularly in small environments. So again,I am not wholeheartedly saying "always swing." But to say that it only has a place in same-hardware and/or same servername scenarios is to dismiss some very real benefits and, more often than not, such claims are made by people that haven't actually purchased a swing kit and read the documentation and understand *why* it is different than the official MS method.
I wanted to clear that point up so an accurate and clear decision can be made by *whoever* happens to read this thread in the future, not just the OP.
Thanks,
-Cliff
 

Ok, I understood from other posts that the MS migration path could be a bit of a nightmare - but then I could use a different domain name - I don't think thats likely to be a problem and will probably simplify the process a little - possibly ?

Dave_AND mentioned a microsoft solid Migration path for 2003-2008, I wonder could you let me have a url  - thaks Chris.