Customer Migration... more like customer confusion

Question

I have recently been put on a customer migration project, making customers change web/app/retail experience. The company I work for has acquired another company in the same industry.

Everywhere I have seen this done before, the explanation to the customer is company 'x' has merged with company 'y'... creating company 'z'.

My company has re-skinned/rebranded the acquired company with the same brand and colour palette. The UX/UI are slightly different. We currently have two company x's on the App Store.

My company is now explaining to the customer. Hey, company 'x' has acquired company 'y' and made it company 'x.1', and now we need you to move from company 'x.1' to company 'x'.

I'm confused writing this, so the customer must be lost! The user fear will be around migrating money in wallets, accounts, passwords, transaction history, through physical and digital channels etc.

Does anyone know of this being done before? Or any UX customer migration advice/case studies or words of wisdom.

Thanks in advance for your help \o/

Answer 1

The problem with the scenario you describe appears to stem from renaming product Y to X.1. Now customers are confused about the difference between X and X.1. Which is "better"? Which one should new customers use? Do current users of X need to switch to X.1 (it's "newer")? Users of Y might think there's no reason to bother with X.1 because it's a different product by a different company. Etc.

To avoid confusion, product Y naming should have been retained. Instead of renaming it "X.1", it should have been called "product Y (v2) by company X". Development over several versions could converge with X, so that the backend is shared/migrated gradually over time. When it is finally time to discontinue Y and fully migrate everyone to X, users of Y will be familiar with X because of the "by company X" branding.

---

From a customer perspective, when company X takes over company Y, options include:

• Stick with product Y, and its direct successors, for as long as possible, even when it is no longer supported and full of security holes. This is kind of what happened with Windows XP. People were okay with all the XP variations, but Vista was too much like an entirely different product that many refused to "upgrade". (Then MS went and repeated the scenario with Win 8 and Win 10.) I know people who are still using long-discontinued products.

• Migrate to a different product. As support for product Y is dropped and it becomes obsolete, customers often eventually switch. Company X hopes that customers will switch to product X, but my personal inclination has been to switch to product Z.

Reasons I tend to switch from Y to Z instead of Y to X:

• There was a reason I chose Y over X. That reason didn't go away when X acquired Y.

• There may be reasons I prefer not to interact with company X, such as poor tech support or particularly buggy software.

• Dropping support for product Y caused dissatisfaction and distrust.

What might company X do to encourage migration from Y to X?

• Honor existing obligations to product Y. The more familiar people become with company X, the more likely they are to stick with it. For instance, if Y was scheduled for 5 more years of support, support it for at least 5 more years. To avoid confusion, such as what you describe, product Y naming should be retained. Instead of "X.1", it should be called "product Y (v2) by company X".

• Develop products X and Y convergently so that they eventually share the same features and backend. Change the interfaces so that they gradually resemble each other with each successive revision. When they are essentially the same product with two different names, migrate all customers to a new unified product (so that it does not appear that users of X are being favored over users of Y).

• Ensure feature parity between the products. Make sure the reason people initially chose Y over X is covered by X. If X lacks any essential features, there is no way for customers who need them to migrate to X.

• Actively support migration. If the customer is left to perform the migration on their own, they are likely to attempt to switch to another product Z, especially if company Z offers to actively assist migration efforts.

Doing all of the above is very resource intensive, and few companies seem to be able to do it well. Other options include:

• Develop products X and Y in parallel so that they remain separate products with similar features indefinitely. Do not attempt to force migration from one to the other.

• Develop products X and Y divergently so that products fill different market niches.

• Discontinue product Y. Integrate desired technologies into product X. Make no effort to "retain" customers.

Answer 2

Thanks for your response Xiota. My headspace has been where you are at with your advice...

Sadly the rebrand has already been made before my time, and reasons for the change/migration, is and isn't a technology solution. From a corporate perspective they sold $xm in marketing synergies to the shareholders, yet have kept quiet on the $xm in technology migration and lost $xm in customer retention. The company is an old school company in an old school industry (heavily regulated - meaning the cycle to get solution go ahead is laborious), and are quite digitally immature.

Meaning, it is not a software company doing versions etc. But a decommission of, and merger of back-end technology stacks. The option I have been given is your final point/option.

i.e. Design me an experience in discontinuing product Y that has been rebranded already as product X. Migrate customers from product Y(X.1) to product X. (Incentives include here is some money $20-100 to merge accounts.)

From a customer experience perspective, and design perspective, I do not agree with this.

Answer 3

I'd like to share an experience as a user in a situation similar to the question posted here. Due to COVID-19, there have been some firms shutting down and in Singapore where I am from, a short term car rental company (named Smove) has ended its businesses and transferred their clients to another company (named Drivelah) providing a similar service. It's not the same as the business model as the cars in Smove are owned and maintained by Smove, whereas the cars in Drivelah are owned and maintained by private owners. You can see the press release here.

This transaction took place a while back before I stumble on this question, and unfortunately I could not retrieve the email as I had deleted it a few months ago. But as a user, I had a nice (bittersweet) ending with Smove as their final email left me a feeling that I had been taken care of by the company. Here's what they did.

1. Explain what happened - Smove was clear and straight to the point on the reasons why they had to close down, and thanking the users for being with them for the few years that they were in the market.
2. Assurance - They also assured us that our accounts and all the balance credits we have with them will be transferred to the new company. The way this was written in the sense similar to a parent telling the child that that stranger can be trusted as much as they did.
3. Transparent - Lastly, they were also transparent about what would happen to the data and the process taking place to transfer our accounts from Smove to Drivelah. It was assuring and clear on the steps that they would take, and they also asked us to be patient while this was taking place.

To date I have yet to receive email from Drivelah, probably it'll take another few months before it happens, so I'm waiting to see how Drivelah would handle this. And since I'm not a superuser of the services, I'm happy to wait. Not sure how other users would feel too. The important takeaway is that Smove really took into consideration the user experience when they had to exit the business.