The simple answer is “no issues”.  Priasoft does not depend too heavily on the actual user account for any sort of authentication during the migration.  Our access to the environments is done with system privileges that are not affected by individual user accounts.
However, there are some subtleties to be included when developing any strategy for an Exchange and AD migration combined.
Keep ’em separated
In our experience, the first and best strategy to work towards is one where the Exchange migration and the user account/Active Directory migration happen on different timelines.  Projects that attempt to combine the 2 tasks in the same event often create many unexpected issues.  The first of which is simply triaging at the helpdesk.  When support tickets start to come in the day after such a migration, it is difficult for 1st and 2nd level support folks to determine if the issue is related to the Exchange migration, the AD migration, both, or neither.  As a result, tickets stay in queue longer than usual and users become frustrated.
The second issue we see with a combined migration in the same event is that AD migrations are rarely as smooth as an Exchange migration.  A common results follows a pattern where, in small scale testing things seem fine for an AD migration effort, but large scale/entire business migrations present issues that the small scale test could not have shown, for example:
Due to the depth of involvement that Active Directory has on an organization, there are many applications that use it for security and authentication.  AD then is more than just the value of the attributes for users – it is the basis of the entire security framework for an organization.  As such, what we have seen are cases where the AD migration is planned to include all users, but shortly after (or even during) the AD migration completes, some users begin to complain about issues with applications.
The typical complaint is that XYZ application, which is important for a user’s job function, is not working.  The user is unable to open the application.  Upon review, it is found that since the user is now logging in under the target domain, the application fails to start because it still expects an authentication from the source domain.  The user, now unable to perform his/her work function, is quite upset and demands to be reset and made to logon back in the source domain.  However, this user is not the only user that works with this application – the whole department uses it.  The department manager learns of the issue and demands that his entire department be reset to logon in the source domain.
Immediately a situation arises where some users are logged on to the target domain, and others are logged on to the source.  A secondary issues ensues with Exchange, because the mailboxes were also migrated in the same event.  Now that those problem users are logging on to the source domain, they cannot seem to access their mailbox in the target domain.  This should make sense because those users are authenticating to the source domain, and those accounts don’t have ownership or permission to the target mailboxes – the result is that Outlook is prompting users for credentials (because the initial attempt using the source account failed).  The user is confused by this and enters their source credentials a few times before giving up.  Worse, because of the way Outlook and MAPI work, TWO FAILED ATTEMPTS causes 4 actual failed attempts – each Outlook logon equates to 2 logon attempts to the DC.  This can quickly lockout a user’s account.  If the user was experienced enough to know to put in his/her target domain and username, he/she might likely use the source password out of habit, and if it doesn’t match the target would lock out the account.
For these reasons, Priasoft HIGHLY recommends separating the 2 tasks into 2 separate projects.  Allow one to finish completely and allow for a week or so of post-migration response to occur before engaging the second phase.  This buffer in time allows for better triaging if issues and gives a chance to see if issues arise that might, justifiably, postpone the second phase.
 
Recommended Order
Priasoft recommends that Exchange migration first, in front of any AD migration tasks.
Our reasoning comes from experience of seeing the results of the different patterns.  When Exchange is migrated first, this has an immediate gain in perception about the capability of the IT group.  This positive gain can offset and provide some leniency when follow-on projects are executed.  Users and managers will remember how well the Exchange migration was executed.  The CEO will feel the effects of Exchange issues just as quickly as any other user, but issues with SQL servers, websites and the like may not surface to senior executives in the same way, especially if they don’t normally interface with such applications.  Given such high visibility of this core business service, a smooth transition becomes very valuable.  In contrast, an AD migration can certainly affect the perception of an Exchange migration – if Exchange was migrated 100% properly, but due to the scenarios above or others where accessing a mailbox is challenging the effort can be perceived as a failure.  Lastly, a properly executed Exchange migration that takes these concepts into consideration and protects the end-user experience also means that when subsequent transitional projects begin, users will be able to effectively communicate about the issue – that alone can help soften the negative perception of an AD migration or other project.
Migrating Exchange first also relaxes the demand to “migrate all users” at once.  The approach then to an AD migration can be done in smaller chunks and with more respect and response at group and department needs.
Microsoft has supported such an approach for over 15 years – this idea goes all the way back to Exchange 5.5 in the 1990s.  When Exchange 2000 came out, it supported a feature whereby users in one domain could be marked as “owners” of mailboxes in another domain.  This was, at the time, called the “Associated External Account”.  This name carried forward thru Exchange 2003 but was renamed to “Linked Mailbox” starting with Exchange 2007.  The Linked Mailbox feature allows a user in the source domain to own a mailbox in a remote domain and as a results provides inherent single-sign-on capability.  The Monday Morning Experience following an Exchange migration is nearly transparent because users will not be prompted by Outlook to access their mailbox, which matches their experience on the Friday before.
When the time comes to migrate the AD user accounts, it is a simple step to convert a Linked Mailbox to a User Mailbox and the result is that the user experience is again maintained: the Monday Morning Experience after the AD migration is one where, at least with Outlook, the user still is not prompted because they are now logging in with the account that actually holds the mailbox.
 
AD First, Exchange Second
If an organization if absolutely forced to support this model and approach, Priasoft recommends delaying the migration of any mailboxes until ALL accounts and security groups are migrated to the new domain AND USERS ARE LOGGING ON IN THE TARGET DOMAIN.  That latter phrase is most important.  One can migrate accounts in a “pre-staging” effort, but such has no value on user experience since in that scenario users would still be logging in to the source domain.  After users are logging into the target domain, and a week or so has pass – to see if any departments or users need to be shifted back – then Exchange migrations can start.
Our recommendation for this approach is partly because of the previous statements about users needing to be reset and made to logon to the source.  While an environment is “split-brained” between 2 forests, there is often much confusion and support for applications due to the difference in where the authentication occurs.  The other reason we recommend this approach is related to how the Exchange migration is executed.
Migrating mailboxes, the data in them, the address book details (which is really Active Directory), and possibly Public Folders, is conceptually simple and really only involves data stored in servers, this is not enough to have the perception of success by end users.  Access to the new mailboxes and new mail system are almost more important – it does little good to quickly migrate 100s of gigabytes of data only to have issues with users accessing that data.
Outlook is a primary component of success.  This means that in addition to all the backend data movement, proper treatment of the Outlook experience is necessary.  There is a hugely misleading idea that Outlook has some ability to understand a cross-forest migration.  This is simply not true!  The fact is, Outlook does NOT have any understanding of a cross-forest change.  AutoDiscover – which is claimed so often as the ‘fix’ – is not a feature of outlook that fixes things.  AutoDiscover is simply a list of “connection points” that Outlook should use, at the moment, for connecting to certain services.  What is not discussed or documented by Microsoft is the fact that Outlook can and does have hidden configuration elements that point to Domain Controllers, Global Catalogs, and Exchange servers that are not updated by details returned with AutoDiscover.
As a result then, Outlook may connect to the new target mailbox initially without issue, but unbeknownst to the user and many administrators, Outlook is also making connections to those other servers, which in this case would be in the source environment.  The issue appears after a migration completes when those source servers are taken offline, or are unresolvable, or otherwise unreachable.  At that point, Outlook starts to lockup intermittently and without explanation.  Some users have the issue and others don’t and the help-desk answer at that point is “make a new profile”.
This impact with Outlook and the user experience can be avoided because Priasoft has a first-class update utility that PROPERLY resets an existing Outlook profile to the new mailbox, clearing any and all legacy connection pointers.  The tieback to the AD migration is with automation.  While Priasoft does provide a tool to do such updates, the automation and delivery of the update is left to the organization administrators.  The reason is due to the fact that Outlook profile details are stored on users computers, in their computer registry (HKEY_CURRENT_USER).  Many organizations already have an approved and supported platform for distributing changes to users desktop – Priasoft did not find it smart to try to force an additional one on customers and such would have likely created other conflicts.
So, automating profile updates is a key component to success – unless admins and help-desk folks are ok with running around to each desktop to delete the current profile and create a new one.  Active Directory, out of the box, provides a simply mechanism to deliver changes to user’s computers: the logon script.  An AD Group Policy (GPO) can be used an associated to users, groups, organizational units, or the entire domain (recommended) to cause the Priasoft profile update utility to execute and update profiles following an exchange migration.
There are also other, more robust solutions available like Microsoft’s SCCM and Altiris, ScriptLogic and so on that provide deep desktop management solutions and often with an active “agent” on users computers.  These can be used just as well as a logon script to cause changes to Outlook profiles.
However, regardless of the choice of automation, they all rely on Active Directory.  If AD is migrated first, and an organization ends up in a “split-brain” scenario, automation becomes challenging since the automation then would need to be managed in BOTH environments, depending upon to which environment the user authenticates and to which environment their computer is joined.  Mistakes in this complexity mean that the Monday Morning Experience may be impacted if profiles are not updated – because one group thought the users were logging into the source domain, but the automation was applied in the target, or vice-versa.
One final note about migrating AD users first.  When this option is used, and if single-sign-on and the Monday Morning Experience is important, SID History should be migrated forward with the users.  This action will allow users that logon in the new target domain to access their old mailbox without a credential prompt.  It is important to understand that SID history, by definition, is a backward looking feature meaning that it only helps with accessing old resources, like a mailbox is a previous domain.  Migrating SID history prior to users logging on to their new target domain has no value for end users and actually can cause migration problems.
 
AD Does not have to be migrated
Lastly, for full coverage of the ideas presented, there is absolutely NO requirement at AD users must be migrated.  In fact, there are many large organizations that take this approach and Exchange is hosted internally in a separate AD Forest simply as a service.  No user is ever intended to logon directly in the Exchange Forest.  This model is also referred to as a “Resource Forest”.  This idea has its own merits and benefits, and only some very small detracting points (which are easily overcome by scripting or 3rd party management tools).