Background

Let me explain what this means first and set some criteria for a statement like this. In the majority of cases this would involve moving little to no data which is usually the recommended approach for such a large cutover (a.k.a. flash cutover). Coexistence between on-premise mail systems and BPOS can be problematic and confusing for users as well as administrators. Shortening or eliminating this coexistence period is usually a pretty high priority goal for any mail migration project. We try to urge most customers to go with "green field" or minimal data such as calendars and contacts and maybe a few days' worth of email. While this might not seem like a lot of data it can still take several hours or days to move this data over given the number of seats involved and depending on the migration tools you're using.

Normally migrating this many users over a weekend doesn't just involve simple mail migration. There are also related requirements that need to be in place like:

• Deploying the SSO and Outlook clients
• Possible (re-)training for users and admins
• BlackBerry devices need to be re-provisioned in BPOS, Windows Mobile/ActiveSync devices need to be updated to point to BPOS
• Application integration testing and re-tooling to work with current workflows including email
• Running a pilot or two
• Testing all the above and more

There's also that dreaded post-migration support call barrage you just know is coming even though you've communicated How-To and FAQ docs and trained your staff so they're a lean, mean supporting team. Even will all of these challenges it still can be accomplished with a lot of proper planning and testing.

Back to the question at hand: How can you flash cutover 5000 users over a weekend, especially if you want to do a pilot or two ahead of time (without rolling them back)? You might also ask, what is the big problem here? Let's say you have registered your BPOS SMTP domains as external relay. This means that email sent from other activated BPOS users will be attempted to deliver locally to a BPOS mailbox first, then to your on-premise mail system via the MX records. The problem begins once you activate a BPOS user and you don't migrate them, meaning, they aren't treating it as their primary mailbox and mail is not forwarding to their BPOS mailbox. Once this activation occurs, mail flow back to the on-premise mailbox is broken, simply because there is already a valid local mailbox ready to receive messages. You end up with dual mailboxes for some folks with mail sent from other BPOS users ending up in the BPOS mailbox and mail sent from the on-premise system in their local mailbox. Unless the user is set up to connect to both mailboxes, they might never know they are missing mail.

The Strategy

Ok, I understand the problem. How do I fix it and still do pilots and a flash cutover?

Well, you simply set up mail forwarding in BPOS to forward mail back to the on-premise mailbox. Normally for on-premise to on-premise migrations the administrators can take care of all of this usually with whatever migration tool they're using or even a script. With BPOS, at least for now, you need to work with the BPOS support team to accomplish the same task. As of this writing, there are no BPOS PowerShell cmdlets available to set forwarding, although it's quite possible they will be available in the next major release of BPOS (a.k.a. Wave 14). Normally in Exchange we would use the targetAddress field to control where mail gets routed. For BPOS we establish forwarding through use of contacts.

Here's how it works at a high level:

1. You establish your directory sync between AD and BPOS.
2. You create a matching contact in AD/Exchange for each user participating in the flash cutover and pilot
3. You sync these contacts to BPOS
4. You mass activate the BPOS accounts
5. You submit a request to BPOS support that you need to establish email forwarding for the list of mailboxes and contacts you'll provide them in CSV format. You only need to include the mailbox's SMTP address and the contact's SMTP address in the file. They will run a script that will establish the forwarding. Be sure to request whether or not the mail sent to the mailbox will be stored and forwarded or just forwarded.
6. After you receive confirmation that the forwarding is in place, you'll want to hide these contacts in your local AD by setting the msExchHideFromAddressLists attribute to TRUE or you can use a utility like AD Modify to perform a bulk operation and set this value.
7. Run another dirsync and the contacts will be hidden in BPOS. The key here is you want BPOS users to send mail directly to the mailbox and not the contact.
8. Test forwarding from BPOS to the on-premise mailbox. If you're satisfied with the results, you're ready to proceed with pre-staging data and piloting.

Here's what the mail flow looks like during this period:

What You Need

For this option you'll need the following:

• Local SMTP domain – one that your on-premise mail system can receive mail as (i.e. MX record points to on-premise mail system) and is also NOT registered in BPOS.
• BPOS directory sync tool
• AD with schema extensions for Exchange 200x

Ok. Now fast forward to the flash cutover weekend. Aside from migrating any last remaining data you'll need to break the forwarding on the BPOS accounts. Gladly, this part is under your control. Simply delete the local contacts in AD and run a directory sync with BPOS which removes the contacts along with the forwarding. Now, if required as part of your migration strategy, set forwarding on the local mailbox to forward mail to the cloud mailboxes. This is usually accomplished through the migration toolset. Yes, we're reversing the flow here. Since you now have a new primary mailbox hosted by BPOS you'll want to make sure new mail that ends up in the old mail system gets forwarded to the BPOS mailbox.

In Summary

Benefits/drawbacks of this solution:

• Benefit – you can mass activate all your users and still have coexistence and run pilots.
• Benefit – you can pre-stage data well in advance of the cutover weekend allowing you more time if more data is needed.
• Drawback – pre-staging data can be problematic in that usually data is migrated as a snapshot of what the on-premise mailbox looks like at the time you migrated that particular user. Any subsequent changes might not end up in the same folder or status the user has it in when they get cutover. You might end up with a lot of calls about this so proper and frequent communication with the users is necessary.