I am someone with a common name.  I have the great honour to be someone who gets hauled away for mistaken identity at international airports. (It is always a great welcome / welcome back) 

In any migration, Name Collision is a common problem that needs to be addressed during the planning stage. Common issues include:

• Data going from the acquired user to an existing user
• Merging SharePoint / Shares when you didn’t want to
• Acquired users not knowing their logon name
• Acquiring user getting renamed/disabled/other issues
• Mass confusion

Let’s look at this issue at both the user level and the department level.

Users

User issues are like my airport problem: two people with similar names.  Typically, someone with an incoming account has the same logon name as an existing user.  In this case, you need to rename the user coming in.  Some companies have policies that if the incoming person is a high-level exec, they can take that existing person’s logon name.  I do not recommend this policy on so many People and Tech levels.  In these situations, I have found it is better to give the exec coming in several options or to allow them to make a custom request. In smaller orgs, typically you can let the user in conflict choose an address that solves the conflict.

If the user is keeping their old domain in the move, then you may choose to just swing this over and give the user a unique identifier for vanity addresses if needed.

If the user is taking on the new domain, then they will need a new address and to be informed of this change.  If the old domain is coming over as a secondary address, you want to ensure your processes add the correct SMTP address to this account.

I always notify users with name conflicts, both the existing staff person and the joining staff person, of the problem.  This puts them both on alert for issues and makes them aware that they should raise a ticket quickly if something is wrong.  It also allows them to start a mail forwarding relationship, something my friend Mary and I worked out at a previous job.

Department Names / Shares

Department names / shares are another common issue.  Before the integration, there were multiple shared service departments running with similar names.  As a result, there are multiple shares with the same names in both the source and the target.  Examples include HR, Finance, Accounts, and so on.  During integration, many companies don’t want to brand staff with their previous name.  We want to move forward as one strong company.  However, this is where, for clarity, we need to address  this issue.

The easiest way to address this concern is to pick a 2-3 character abbreviation for the company, and pre-pend all of the shares.  The Finance share becomes CON-Finance.  However, you may not want to choose something dodgy like CON for a company like Contoso. 

Another tip. . .if you operate in several countries, you may want to run the proposed names by other multi-lingual friends in the other offices.  Fun fact, ‘prd’, short for production, means fart in Slovak, so it really is worth checking these things from time to time.

Key Takeaway

Do not make processes that fail to handle name collision.  Never make a master mapping based on just an assumption that every name comes over.  These practices will really cause you problems in the most spectacular of ways.