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.
Each scenario might be slightly different for customer password migration, but at the same time, there are four main strategies that you can use:
- email reset
- store hash in custom attribute and change pass on the fly
Let’s take a look at them in a bit more detail.
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.
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:
- the system sends to customers email that the new site is live with a call to action button to set up a new password
- after user click on that button, redirection to the page happening where the new password can be settled up
- 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.
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.
My name is Oleg Sapishchuk, and I would like to reward people who helped me during my career, gaining the knowledge that was enough to write this new article. Kudos goes to Thomas Pasquet (Chief Technical Lead Salesforce Commerce Cloud at ITELIOS), Jordane Bachelet (Senior Technical Consultant B2C Commerce at Salesforce), Daniel Anechitoaie (Senior Solutions Architect at OSF Global Services) and Claudiu Cudla (SR Solutions Architect @ OSF Global Services).
I write about Salesforce B2C Commerce and if you are interested in new or already written materials I welcome you to follow my Medium profile.