A customer was recently wondering how he should use the Quest Migration Manager for Exchange Free/Busy synchronization when migrating from Exchange 2003 to Exchange 2010 in an Inter-Org Exchange Migration.
The customer Exchange 2010 Environment was in native mode and did not contain System Public Folders to Keep the Free/Busy system messages.
Does that mean, updated Free/Busy data will not be available during the mailbox migration period where we have to maintain mailboxes in 2003 and 2010 in coexistence?
The answer is no.
Free/Busy data is maintained by running the Quest Calendar Synchronization (either uni-directional or bi-directional) between the corresponding mailboxes in source and target Exchange Systems.
Even when we have a target Exchange System with Free/Busy System Folders, we do not have to configure a Job for the Free/Busy Synchronization Agent. The Calendar Sync Agent takes over the Free/Busy publishing. You can find this action reported in the Calendar Sync Agent log (EMWCSA.log). The Free/Busy publishing period can be configured in the config.ini file of the Calendar Sync Agent, a smaller time period speeds up the Calendar Sync performance.
Recommendation: Make sure that you’ve deployed a sufficient number of Calendar Sync Agents to ensure a quick sync cycle. You do not need a dedicated Free/Busy synchronization job then.
Recommendation: If your target Exchange System does not contain Free/Busy System Public Folders, set your Free/Busy Publishing Period in the config.ini file of the Calendar Sync Agent to 0.
Cloudy Migration Life 
Question – does this f/b scenario only apply for 2003 source? Or, are these statements also valid for 2007/2010 source environments as well?
In terms of calendar synchronization there are no differences how the agents are updating information. The question is if you have Free/Busy system folders or not. If you want to use the Free/Busy sync agents, Free/Busy system folders in source and target Exchange are required. In either way, running Free/Busy sync is never mandatory and can be completely replaced by calendar sync, assumption made, that you sync all your calendars from the beginning to the end of migration.