Wow, that is a lot of questions with a huge scope. I don't mean to be rude but I think your best approach is going to be to research most of these questions extensively yourself and build up a very complete picture. It's not something we can really cover properly for you in a single thread. A migration like this is a big undertaking, it'll need time & budget & project management, not to mention keeping one eye on politics and not pissing off your users ;)
Anyways, I'll speak to some specifics which you may not be able to easily find elsewhere. I (and 1 colleague) migrated a Domino 6.5 environment across to an Exchange 2007 system in May 2008 at an organisation of 250 people, in the UK. These points were all learned along the way when we did that migration:
First - Architecture
In ex2007 you need to grok the various roles. I would recommend that you deploy a hub transport, information store, and client access
roles at your primary site, an information store at your secondary site, and no roles at your branch offices. Instead, use RPC over HTTPS or existing VPNs to connect back to the central exchange.
However you need to tailor the above to your organisations needs and limitations. If you have weak WAN links but a strong Internet pipe at the secondary site, and they run under a seperate email domain, you might want to deploy a hub transport there. If your business is security-focused, you may wish to deploy an Edge transport in your DMZ (but this is not mandatory). Depending on your hardware you may need to purchase new servers (you need 64-bit kit for ex2007 as a minimum) and/or bump up the RAM. Ex2007 loves RAM.
Second - Preparation
Your biggest pain point here is if Domino is being used for 'non email' business purposes. Domino is a jack-of-all-trades database system and is often used for things like document stores or form-input databases. You should focus on decomissioning all non-email uses of domino, primarily by identifying stuff that's not even used any more and removing the NSFs, or for stuff that is in use, migrate to something else e.g. extract the documents and put them on a file share. This takes time, but you can address it in parallell with your main migration, and if necessary keep the Domino server around for a while even after the email roles have moved to Exchange.
Third - Migration
Invest in the Quest migration tools. You're mainly paying for Quest's support, and they'll help you out through the course of your migration and won't stonewall you if your question isn't strictly related to the Quest apps - They have a lot of migration experts who have tackled your scenario 100s of times over. Worth their weight in gold.
Other stuff
Blackberry - Talk to your account manager at RIM (if you don't have one, your supplier will). They will be able to supply you with a 'temporary' enterprise BES CAL set for the duration of your migration. So you purchase the Exchange version of BES, build it alongside your Domino BES. Then you apply your existing BES CALs to the new server (no need to re-purchase the CALs!) and apply the temporary licenses to the old BES server. This gives you a 30-day period in which you have co-existence, you save money by migrating your CALs, and the temp CALs they give you should be free or a fairly nominal cost.
Clients - For the user side of the migration, leverage the rich OWA in Ex2007 in cases where your users don't yet have Outlook available or configured. This is good becuase it:
- Gets users used familiar with OWA.
- Requires no migration dependency on client-side existence of Outlook.
- Is low-maintenance which means you don't get dragged away from the migration work to fix client issues.
Cruft - Standardise and reduce as much of your system as you possibly can before you begin migrating. Remove all mail NSFs for users who have left the company, and clear up any instances where managers are still accessing them. Update all database designs to your current version (if you've previously upgraded Domino and still have old templates lurking). Get management to review BES usage and clear off users who don't really need it. The more non-core data and configurations you can remove before you begin, the easier your migration will be.