I agree with mtj's answer that the user's have no vested interest in jumping through hoops for your internal data's sake. However, I don't quite agree that that means you can't merge your databases.
To summarize the below detailed explanation, the trick is to favor the user experience, and avoid needless spam or requests for action. Instead, the systems should accommodate a transitory phase that allows the users to make the switch if and when they are ready (within a reasonably broad time frame).
A has a certain dependency on email, and one of the crucial feature it has depends on that; a customer from B might have an email, but that has to be verified before it can really be used in A
If B was already using this email address, then for all intents and purposes these emails are already considered to be valid (and therefore validated).
A's requirement to validate email addresses is a business decision, not a technical necessity. Here, you should favor the user's quality of life and therefore not needlessly invalidate their (up until now) perfectly usable records. Lift the validation requirement for the migrated accounts.
If some B users do not have an email set up, and this is required for A, favor unintrusive features. If you can import them without email and prompt them to fill this in when they log in to A, that's the least intrusive and most user-friendly approach.
However, if the email is a true necessity to migrate (e.g. because it's the login credential, then I suggest favoring not migrating these users immediately, but instead letting them log in to B and upon login, present them with a migration option where they supply any missing data.
A was operating in the same region for a long time as well, so there can be users who signed up for A before, who are users of B as well- so possibility of duplications
It's very contextual if email addresses are considered unique enough for this purpose. Maybe multiple employee accounts all use the same general email address, and so it's impossible to distinguish them.
It's also contextual whether there is data that needs to be merged, or if it sufficies for the users to have an account, regardless of any B-specific data needing to be imported into A.
Some online platforms specifically prompt the user to merge their accounts, in case you find duplicates. In other words, you import the B accounts, and flag potential duplicates. When the user logs in and has flagged duplicates, show them the A and B accounts, and give them the option to continue with only A, only B, or merging the two into one account.
How does a customer from B can actually log into platform A, without his password being recreated?
You could have A implement a dependency on B's login strategy, therefore being able to use B's login method, which means you can migrate the hashed password and keep it usable.
You could opt to force the user to change their password on first login, which then uses A's login strategy. When all users have transited (or after a chosen cutoff date), you can remove A's dependency on the B login strategy.
Alternatively, you could still have users log in to B and then prompt them with a migration wizard. This ensures that they are able to immediately choose a new password that can be registered during the migration, as opposed to migrating the data.
The least favorable option here is resetting the migrated users' passwords.