As noted by MDMarra, you can't. Exactly.
Having said that, I've done a number of seemingly in-place mail migrations for clients in similar situations by replicating the old mail server in a VM on my [powerful] laptop, transferring everything over to that, and letting it be the mailserver for a few hours so I can "migrate" from the VM to the real mailserver hardware (which involves uninstalling the old version of Exchange and/or re-imaging before the new Exchange version goes in). It's not so bad if the environment's small and you've done it before. (Takes me 6-8 hours, assuming nothing unexpected happens.) Obviously, you want a full disk backup copy of the original in case something blows up, and you want to do it off hours, so your VM doesn't buckle under the load.
Honestly, it's a pain in the ass. For what I charge to do it that way, my clients could buy a new, good-enough server to put Exchange on, but... people are weird. I don't get why anyone would prefer to put a shiny new mail server on the same old turd of a server they were running 3+ hardware generations ago, for the same price, but in answer to your question, you can do it if you're not too picky about your definition of "upgrade" and you have anything powerful enough around to serve as a temporary mail server while you do it.
The basic step-by-step outline (broad strokes) of how to do it is:
- Create [disk-level] backup of server. No "wrong way" to do this as long as you get a disk-level backup you can restore from easily and quickly. I have a commercial license for a product I'm comfortable with, but if you have restore-tested backups (and you should, always have backups) those will do too.
- Copy server. I always cheat, since I have the required VMWare licenses and experience, so I just P2V the existing mail server onto my laptop. I suppose there are multiple approaches to this too, including standing up a new server and manually replicating the old setup (not what I'd recommend), or maybe standing up an OS and "restoring" a backup onto it.
- Put VM mail server in place of old mail server. If you're doing a mail cut-over migration (which this is), you should know how to do that. Rename and reIP the two servers as desired. Note that you want as little delay between completing 1 and 2 and getting 3 in place as possible, because if you have mail bouncing or going to the "wrong" copy of the mail server, people are going to be missing mail. "What the hell kind of loser sends you email at 2AM on a Sunday" isn't an acceptable excuse either (in my experience), so make sure your backup and virtualization copies are up to date. Preventing the "old" mail server from receiving mail while this is happening is really the best way I've found to do it, though if traffic's low enough, and the environment's small enough you can always worry about migrating a handful of messages manually after the fact.
- Install new Exchange on old server. Make sure 3 is working first, of course. I prefer to wipe the box and start with a clean OS install, instead of the OS upgrade you mention, but either works. (Less variables when you're not retaining all the old configs in an OS upgrade.)
- Migrate mailboxes and settings from VM to physical server. Easiest with something like Quest Exchange Migration tools, but not so hard to do manually either. Pain in the ass, but not hard.
- Power off VM.
- Cut-over (cut-back?) to physical server. Pretty much the same as 3, only in reverse. And again, be quick. You really want to power off the VM, and then immediately hit
Apply to make the changes live on the other server.
- Test to make sure it's working.
- Notify principal(s), collect payment.
As to specifics of an Exchange 2003 to 2010 cut-over migration, there are far better guides out there than anything I could punch up while watching test runs at the day job, so, consult one of those. Google is your friend, as are the Exchange forums at Technet, that even have a subforum for the topic.
And if you have access to a VM environment, test, test, test this first. Test setting up Exchange 2010. Test P2Ving Exchange 2003. Test transferring everything between two VM mailservers. Test it well enough that you can do it from memory before you touch your live system. It's a lovely way to get all your learning and mistakes out of the way somewhere no one will notice.