We have already gotten a few parts down of our GO-LIVE story, but we are far from done. Going live with any Commerce project can be quite an endeavor. But hopefully, with this series, the most critical parts of the puzzle are covered!
On to the next piece: Customer migration!
Although this series is about GO-LIVE, which happens at the end of a project – a lot of preparation goes into it, even weeks and months in advance.
Data migration should be in your planning as soon as possible, as customers who existed on a previous platform (which usually applies) must be migrated.
The main reason to start this sooner rather than later:
You are, in most cases, not in control!
What I mean by this is that the implementation partner of the previous platform needs to share the data with you, either in their format or in the one that Salesforce B2C Commerce Cloud uses.
And since this is sensitive data, processes need to be put in place to ensure the transfer of information happens securely!
Decide who is in charge
Salesforce B2C Commerce Cloud only allows formats it defines, which means that with any migration, some transformation needs to happen from the format of the previous platform to that of SFCC.
And there is only one option: XML (Business Manager or Automated job).
But what do you mean by “who is in charge?”. Well, who is going to be doing that transformation? Depending on the answer, this will affect your planning.
There are a few options for who takes ownership of this:
- The Consulting (Implementation) Partner
- The Salesforce customer
- The previous implementation partner
Ultimately, it does not matter who does it as long as they have the required knowledge of both the old and new formats. There is enough documentation available to get anyone started on the process, and guidance from the Implementation Partner is always a good thing.
Handle with care
I have mentioned this before, but we deal with people’s personal information in this process! Be sure that the data you work with is handled properly!
Transfer the data securely, and only transfer it to people who need to work with this data.
😱 Don’t email the database unencrypted to everyone involved in the project. 😱
And also important, once the people have done their task, they must delete the data from their systems.
Make a deployment plan
Work out a detailed plan on how you will do this migration. In many cases, the old platform will still be up and running a few hours before the scheduled go-live.
So what about the registrations and account updates between the last export and when you go live? Think about, and discuss with the team how to handle the last delta import to make sure no data is lost.
Make these steps part of your deployment plan, and decide who is in charge of each step.
Compare and test
After converting the data, run extensive testing on the source and target file to ensure no data has been mixed up.
This might seem obvious. But we don’t want to link the address of person A to person B accidentally, do we?
I will not elaborate on this one too much, but compared to the other data in a customer migration, this tends to be the most challenging.
Why is that? Well… better hope you get this data encrypted or hashed! Otherwise, the previous platform had some severe security issues. And because of that encryption/hashing, you need to find ways to handle this.
To dig deeper into this topic, I will redirect you to an excellent article by Oleg Sapishchuk.
The final step, as with many things, is monitoring after go-live. Make sure people can log in – and make Customer Service aware to note down all the information to track potential bugs.
It is vital to keep this part of your daily routine for the first few days (amongst other things) after the big release.
With any big release, make sure you also have a contingency plan. Things can go wrong, and a rollback might be needed to make corrections.
Like a deployment plan, ensure a rollback scenario is covered with tasks and who is responsible for each. We all wish everything goes as planned, but the reality is not always so kind.