Colin’s IT, Security and Working Life blog

February 6, 2012

Considerations for Scheduling Exchange 2010 Migrations

Filed under: Techy — Tags: — chaplic @ 8:49 pm

So, you’ve designed your shiny new exchange environment, and you’re probably migrating from a creaking Exchange 2003 environment?

In theory, the outage for users takes as long as the size of their mailbox and connection speed. However, most organisations will want to schedule migration in batches probably out-of-hours, to allow for full system backups and operational tests.  It also makes user comms that much simpler.

Obviously it depends on your users work profiles, but if we assume standard office workers and a Monday to Friday working week, how many days to do migration? For the purposes of planning, I’d always include a spare day to allow a rescheduling of a failed migration. So, you could migrate 6 days-a-week, but what about the helpdesk hit when 3 times as many people get their migrated mailbox on a Monday morning?

How do you actually build a schedule for user moves? There are a few choices/ Decisions to be made


  • Per Server – start with the first user and first server and keep going till the last user on the last Server. Means you’ll get old servers shut down ASAP. However, the challenge here is how quickly can the old server spit out data? This is likely to be a choke point.


  • Per Business Unit – will likely mean a random split of users across all source exchange servers. However.. What if something goes drastically wrong – would you knock an entire department out at once? Depending how good your directory services are, just getting this information could be tricky


  • How Many people/ data – Given the speed of your connectivity and source servers (I really hope performance of your new exchange 2010 tin isn’t a concern!) your testing will suggest how much data you can transfer in a single migration window. However, if you could migrate tens of thousands of users in a night as they all had small mailboxes, what’s your appetite for helpdesk calls should even 0.1% of people have problems

Here’s an option that mixes the two approaches.

Firstly, don’t migrate on a per-business-unit approach. This makes scheduling a nightmare, but more to the point introduces the risk of an entire team being knocked out at once. So pick users seemingly at random then communicate with them individually

If you have 5 exchange servers, take one person off each Exchange server and increase your person counter, and also total up their mailbox size. Assuming you don’t reach your limit of number of people to migrate OR maximum data to transfer, then move to the next mailbox server and add the next user.

If you do reach a user or mailbox size limit, then zero your counters and declare a new batch.

Keep adding batches till you have a fixed set, of, say, two weeks s worth of migrations.

This approach should evenly spread the load across all source Exchange servers, and minimises the impact to an individual business area should a problem occur

The logic to actually achieve this is a bit complex. I resolved this issue for a client with a little bit of VBscript that throws all the values needed (mainly from AD)  into an SQL database, then a second bit of VBSCript which produces excel spreadsheets with the user details on them.

Decide how much advance warning you want to give users, 2 weeks from initial communication is probably enough.

14 days before you plan to migrate your first batch, email the users and let them know, inviting then to reschedule if inconvenient.

If you’re increasing users mailbox quotas, be sure to tell them this on the email, because for them it’s probably the biggest feature!

The next day, email your second batch of users, the next day your third batch, and so on.

Obviously, you will need follow-up reminder emails closer to the time. I’d recommend informing users you need at least 48 hours to cancel scheduled migrations.  OK, so we all know that’s not strictly true and important cancellations will still happen at the last minute but hopefully it will reduce the number of last-minute migrations.

Keep the messages clear, short and snappy, but direct users to an intranet site for further explanation and a wiki/ FAQ site.





Blog at