Further detail about how the wizard performs its tests…
Purpose:
The purpose of the tests at the end of the wizard are to ensure that all connections to the source and target environments are working before starting the batch.  These tests were added to provide confidence that, once the batch started, one could walk away from the migration and not be surprised later with simple issues like a database being offline, or a server being unavailable.
In a larger, more distributed environment, there may be multiple exchange databases and servers from which or to which a migration is focused.  It was proven frustrating prior to these tests to find out after a batch started that one database out of several was offline – the result was such that the batch would start and begin migrating several mailboxes.  This was enough for most administrators to assume that everything was ok.  However, coincidences could occur where the active mailboxes were communicating properly, but after a few minutes, or hours, when the batch started work on other mailboxes from another database, failures would occur because that second database was offline or the server was unavailable.  This pattern caused all other work to be block as the migrator would infinitely retry such failures (they appear as mapi issues).
Two Sets of Tests:
There are 2 sets of tests that occur on the last page of the mailbox migration wizard:  server tests and database tests.  The following will detail how the tests are performed in order to aid with any troubleshooting.
Server Tests
Server tests are performed first.  These tests can be a bit complicated depending upon the architecture of exchange.
Exchange 2007 and earlier:
Tests to these older versions of exchange are simplified since connections are per-server.  The meaning here is that there is not a “proxy” connection that can broker a connection to a different server, as there is with Exchange 2010 and later.  The server tests, in order to be efficient, will exit the test on the first database success – this is enough to determine the server is online and accepting connections.  Only if all database connection tests fail will the server be considered a failed test.
Exchange 2010 and later:
Tests to these versions of exchange are more complicated due to the existence of the CAS (Client Access Server).  Since all mailbox connections must pass through these server types, we must validate that connections to all the CASs can be made.  In Exchange 2010 and later, a CAS can accept a connection for a database that resides on a different server.  In fact, any CAS in the same AD Site as a mailbox server can accept connections for that mailbox server – there is not a one-to-one relationship between a CAS and a mailbox server.
In order to determine if a mailbox server is online and available, testing is done by connecting through all CASs in the same AD Site for the mailbox server being tested.  If ALL CAS connections fail, we consider the mailbox server to be offline or unavailable.  The process is one of shortest path:  as soon as a connection can be made to the mailbox server, we consider that server to be “ok”.  Following such a success, the process then proceeds to repeat that test with all the other CASs that exist.  In this way the application can understand which CASs are and are not available – CASs that fail a connection are marked as unavailable with a 10 minute timeout, after which it can be retried.
However, much like with the Exchange 2007 tests described above, a mailbox server is only considered to fail the test if ALL databases on that server fail connection tests.  Testing in this way, when a server is unavailable, can take considerable time, especially if there are many CASs in the site.
Consideration has been made for cases where there may be a CAS that should not be used in testing – perhaps it is a DR site CAS or is down for maintenance.  There exists an ability to exclude one or more CASs from being used.  However, it is not recommended to exclude all CASs except for a single CAS as such creates a performance bottleneck.  The migrator has the ability to aggregate its workload across multiple CASs (much like a load balancer).
Database Tests
Database tests are done by creating a new temporary Outlook (mapi) profile to the SystemMailbox of each source and target mailbox database, based on the databases of the selected source accounts and target database assignments – as such, not EVERY database in an environment is tested, but only those that are part of the batch.  These tests allow the application to report any issues since a failure to connect in this manner will certainly cause mailboxes failures in the migration console.
Shimming
Priasoft has an industry only feature for Exchange 2013 environments where the application can “shim” the connection to force a connection to a specific CAS.  Shimming is where the application intercepts the DNS query for a shared name (e.g. mail.company.com) and replaces the IP address with a CAS specific address.  In order to explain the value of this feature, some background on Exchange 2013 connections is likely of value.
Exchange 2013 has CASs, but they are not site specific as with Exchange 2010.  Furthermore, Exchange 2013 promotes the use of SSL for all connections to the mail system.  A typical and recommended setup of Exchange 2013 is to have a common, shared connection name in DNS; mail.company.com for example.  This common name allows for easier connection routing plans, some as simple as round-robin DNS with others being more complex, intelligent load-balancers.  The issue this presents for migrations is that when multiple mailboxes are migrating simultaneously, all those connections can (and likely will be) routed to a single CAS – there’s no guarantee that round-robin DNS or a load balancer will evenly distribute the connection load across all the CASs behind the shared name.
The migrator does not immediately use the shared name however…it only uses the shared name if direct CAS connections fail to work.  Connections to CASs are performed in the following order, exiting out on the first that succeeds:

1. Unencrypted HTTP connection directly to the CAS
2. Encrypted HTTPS connection directly to the CAS
3. Shimmed HTTPS connection, directly to the CAS by IP address.  The name ‘mail.company.com’ is intercepted and the IP address for exch-cas-01 is used instead.  This forces and guarantees that we are talking to a specific CAS.
4. Normal HTTPS connection.  This final attempt is a standard connection but loses the ability for the tools to evenly distribute connection loads.

So, in summary, shimming is a way for the tools to discretely control which CAS is being used with the configuration does not allow direct CAS connections.

The last screen of the wizard attempts to create an Outlook profile pointing to a mailbox on each source and target database based on the accounts you selected for migration.  The test is no more complicated than creating a new profile manually and seeing if you can open a mailbox.
So, a failure in the wizard can just as easily be validated by creating an outlook profile.  I suggest doing that – creating a new profile – and seeing about what Outlook complains.
Historically, such issues fall into 1 of the 3 following categories:

1. Permissions
   1. The account you logged on with, on the host running the Priasoft tools, does not have sufficient permission
   2. Not enough time has passed since setting permissions. System privileges on databases are re-cached every 4 hours; if you migrate too soon after setting permissions, exchange may not yet recognize them.
   3. The Priasoft Migration suite provides a setup wizard that can both create and refresh service accounts used by the tools.  Running the setup wizard again to refresh/reset the service accounts is worth trying in case any of the accounts have been modified with changes such as group membership, rights, roles, or password issues.
   4. Group Policies should also be reviewed to see if the Priasoft service accounts are excluded from policies, which is highly recommended.  Consider both “group” policies and container policies that would inherit down thru an OU tree structure.  The Priasoft setup wizard creates the service accounts in the standard “Users” container in the domain, which by not being an OU (the Users container is a “Container” object type), is excluded from container policies.  If the Priasoft service accounts have been moved from the default location, they may be subject to policy and receive changes unexpectedly.
2. DNS and NetBIOS
   1. The migration host MUST be able to resolve server names to IP addresses.
   2. Windows always tries NetBIOS resolution first, for single-label names (e.g. ex01 would use NetBIOS while ex01.corp.com would use DNS)
   3. MAPI, being an RPC based protocol often will work with NetBIOS server names and such is out of your control.
   4. When a NetBIOS broadcast for a name fails, windows will then enumerate all the configured DNS suffixes for the host, appending the suffix to the name and sending the now fully qualified name to a DNS server.  However, it is very often found that the host does not have suffixes for the source environment.  Make sure that the host has suffixes for both environments.
   5. Hosts and LMHosts files:  do not use this without direct instruction from Priasoft support.
   6. Target exchange servers may need to perform name resolution to source environment servers.  Suffixes should be applied to target exchange servers as well.
   7. DNS servers in both the source and target environments should have an ability to handle lookups for the other side.  Conditional forwarders are the best option.  The source DNS servers should have CFs pointing ‘target.domain.com’ at a target DNS server, and vice-versa.
3. Outlook version
   1. When migrating to Exchange 2013 or Office365, you MUST have Outlook 2010 and the April 2014 and January 2015 Rollups in order to properly connect.
   2. You should also ensure that all windows updates have been applied.  We have seen many cases where issues are resolved simply due to patches and updates.