0

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.

3 Answers 3

4

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.

2
  • Appreciate your POV and answer, but here's the catch- acquisition happening in a way that there will be no service B. B and A are actually competitors, B is rolling back it's operation from that region, while A is penetrating. More like how Uber sold all the shares to Grab in SEA, and exited. Hope this gives a better understanding.
    – Munim
    Jul 5, 2021 at 4:05
  • 3
    @MunimDibosh: If A outright refuses to keep B around, even in the capacity of being available solely for pre-existing accounts and not being promoted anymore; then A is willfully creating the issue of a very strict and limited migration window. This is going to cause A to either annoy, piss off, or outright lose customers who are not able to respond in this limited window. This is a bad decision, and if A pushes this through, the negative consequences are on their account. Migrationary phases take time, and impatience will cause more problems than it would ever solve.
    – Flater
    Jul 5, 2021 at 11:12
1

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.

1
  • Very detailed explanation. Thank you. I will go through it and try to check against all the usecases and see if we have to tweak anything. Thanks again.
    – Munim
    Jul 5, 2021 at 12:12
0

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.

4
  • Thanks for the answer. Unfortunately, the acquisition won't be exposing the hashing process or source code as per se, and I do not think they will be exposing hashed passwords as part of data either. It's more like business operations & acquisition of customers.
    – Munim
    Jul 2, 2021 at 8:57
  • 1
    @MunimDibosh then they sold you a big pile of nothing. You either have what you need to support those users or you don't. If any idiot from the internet can take over an existing account you have no security. Jul 5, 2021 at 4:37
  • What did they sell you then OP? An email list of their customers? Jul 5, 2021 at 7:41
  • @MunimDibosh: That is the equivalent of buying a second hand car without getting the key. That is a really bad transaction. I would pick this up with the involved management to explain the issues that this causes, because working around this bad deal is going to cost you, both by losing customers and sheer effort to perform a migration around this.
    – Flater
    Jul 5, 2021 at 11:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.