customer.xsd from b2c official documentation

Legacy customers password migration

How to migrate customer password data from a legacy system to Salesforce B2C. Overview of the four migration strategies with migration diagram use cases

When we design a new solution based on the Salesforce B2C Commerce SaaS platform, we always end up with the most important for the business topic — legacy platform data migration. Typical migration data might be :

• catalog product and categories
• rating and reviews
• customer login credentials
• customer profile information with shipping and billing addresses
• customer credit cards or other payment instruments
• customer product lists
• customer auto-replenishment data
• customer orders

Today I would like to cover one of the sensitive topics — customer login credentials and more granularly customer legacy password data.

Photo by timJ on Unsplash

Each scenario might be slightly different for customer password migration, but at the same time, there are four main strategies that you can use:

1. md5
2. scrypt
3. email reset
4. store hash in custom attribute and change pass on the fly

Let’s take a look at them in a bit more detail.

MD5

If the legacy system uses the MD5 hashing algorithm without any salt mechanism, we can migrate the customer password hashes as they are in the Salesforce B2C system directly in the password system attribute. Based on official documentation, it will be enough to specify during such import that the encryption scheme is MD5 and provided password filled is hashed. During the login of legacy customers, the authenticate method from the customer manager class will simply use the same hashing algorithm as in the legacy system and will allow the customer to login. The same approach is followed by scrypt.

Email reset

If, by any chance, the client doesn’t want to mitigate the security risk of passwords migration or there is no technical possibility to achieve the same encryption engine, we always can not migrate the password. In any case, it’s also migration, as the solution behind this process is a process to migrate a customer to the new platform. Instead of migrating data from legacy DB, we are going to build a flow that will allow customers to set up a password in the fresh new eCommerce website. If to be short and not deep dive into details, the flow will be as follow:

1. the system sends to customers email that the new site is live with a call to action button to set up a new password
2. after user click on that button, redirection to the page happening where the new password can be settled up
3. after the user fills out required data, a new password is saved using native SFCC B2C mechanism and customer now can use it for the login process

Of course, there are security details as a unique hash in the email link to validate the user and other specific to design items, but all of them are details, while the main concept is described above.

Store hash in custom attribute and change pass on the fly

The most complex and at the same time, the most used process on the projects I was involved in is about replicating the same encryption mechanism in SFCC as in the legacy system. We did this for Magento and some local Japanese legacy eCommerce systems. We did it in Canada and Europe. The idea, in the end, is straightforward. From a legacy system, we need a hashed password, encryption mechanism description (example with code is welcomed), 2–3 passwords (input and hash) for testing purposes.

In SFCC, in the most basic implementation of the following concept, we can have only one custom attribute with string type to store the legacy hash. At the same time, for easier maintenance, I usually introduce two more boolean custom attributes such as “legacy customer” and “password migrated.” Those attributes are used then in the code for quick boolean condition check for the customer object.

The login flow on the platform for such legacy customers is as follow:

• if SFCC standard authenticate process fails and password migrated for that login is false, we will use a custom one
• custom one use password value from the login form and hash it with the developed encryption algorithm
• we validate the generated hash with the hash stored in the custom attribute for that customer
• if hash matches we update SFCC system password using password value (SFCC will hash it with own encryption); clean up custom attribute with legacy hash and update password migrated value
• if the hash doesn’t match, then the password is not correct

For some more details and to better visualize the process, you can check to bellow the diagram with high-level design details.

Summary

Password migration is not a black box and nothing to be scared of. There are four main conceptual strategies for this purpose, and they are described here. All of them might be adjusted as per your needs, but at the same time, it should be easy now for you to migrate the customer credentials data.

Please find below the diagram that was prepared based on those four strategies we covered today in the article.

Four migrations strategies in Salesforce B2C

My name is Oleg Sapishchuk, and I’m an experienced architect providing digital transformation with unified commerce solutions for some of the world’s best-known and most influential brands. Salesforce B2C Commerce is the topic that I write about most frequently. If you are interested in new or previously written material, I invite you to follow my Medium profile.

I would like to reward people who helped me during my career, gaining the knowledge that was enough to write this new article. Kudos go to Thomas Pasquet, Jordane Bachelet, Daniel Anechitoaie and Claudiu Cudla.