Strategy & Architectural Decision: Customer data migration between two companies

Question

Asked this originally here, and didn't receive any answer so far, hence posting here too.

Let's say company A acquired company B in a certain region. This means, A and B were competitors in that region, and now A will be the only player.

Resulting, customers from company B will need to be migrated to company A customer database, so that they can enjoy seamless experience by logging into app from A. So, the question is more towards strategies that are followed to do customer data migration in such cases.

Problem

• 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
• 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
• How does a customer from B can actually log into platform A, without his password being recreated?

Solution Thinking

• All the data will be migrated from B to A, for emails, a verification link will be sent- the customers should visit the link to verify their emails
• Since they need a password to login, possibly a temp password will be sent to the same email, once they verify; they will be asked to change when they come to A for first time
• For duplicated users, based on same email, the recency of when they logged in last into A will be checked, if it's quite recent no actions will be taken
• If the recency is not latest, they will also be sent an email with temp password saying they need to change their password to re-login

Does this approach look any good?

What other drawbacks or edge cases you can think about or would like to taken care of?

How would you solve it?

Thanks in advance.

Answer 1

Great, more email for the spam folder...

OK seriously now: your business' desire to merge the user accounts is not of concern for the customer.

Therefore, the customer will

• not have any desire for your emailing them
• not have any interest in clicking your link
• eventually not even be an active customer any more who places any value on the account he has
• not be willing to jump through any kind of hoop just to help you sort your databases out

In my opinion, keep the login for both companies separate. "A" customers log in throug A as usual, "B" customers log in through a "B portal" and get redirected to A after authentication.

Maybe add some kind of interactive process for users who login via B to merge their account to A, delete their B account (if you detected a duplicate) or something along these lines.

After 2 years or so, send a mail to all remaining B customers that their accounts will be terminated. These remaining accounts will be dead anyway.

Answer 2

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.

Answer 3

Why do you need to force B's users to reset their passwords? You could copy the hashed passwords from B to A. That said, if A and B use different hashing algorithms, you would need to modify the login process on A to handle that.

Be aware that some people will not click on links in unsolicited emails. Give them an alternative.