Migrating to SAP Customer Data Cloud: Planning Considerations
11 min read
This article will aim to go over everything that you should take into consideration ahead of migrating data in SAP Customer Data Cloud.
A well thought out migration strategy will help you get ahead of common problems every migration project runs into at one point or another, and could end up saving you a lot of precious time.
This article is part of a wider series on SAP Customer Data Cloud migrations. See Migrating to SAP Customer Data Cloud for the full list.
Table of Contents
- Data Source Considerations
- Consent Considerations
- Business Rules Considerations
- UX & Communication Considerations
- Scoping Considerations: Lite Account vs Full Account
- Technical Considerations
Data Source Considerations
This might seem like an obvious question, but many data migration projects get delayed for lack of clear understanding of the processes, internal & external stakeholders and key contact points involved in getting access to your legacy user data, or even finding out about a new source system at the last minute!
Clearly map out the list of digital properties and system for which you intend to migrate users to SAP Customer Data Cloud, and for each of those identify;
- What user repository is connected to the system?
- Whether this database is internal or from a 3rd party identity provider (some providers can require a lengthy notice period)?
- If there are special processes, authorization needed, or even costs to get a data dump that could result in any further delay?
- If all the data can be extracted: does this include hashed password in case of data sources with credentials?
- The password hashing algorithm used if applicable.
If you are implementing SAP Customer Data Cloud solutions, there is a high likelihood that you’ve included SAP Customer Consent. As such, compliance with data privacy regulations will be high on everyone’s mind throughout the implementation, and the data migration project is no exception to this rule.
Next, while SAP Customer Data Cloud allows you to import consent records, it is your responsibility to ensure that those consent records are valid per the applicable regulations. A simple “true”/”false” just doesn’t cut it anymore, and date of consent as well as any other metadata around the consent you might have would be required to make that consent record a valid consent. Again, your Data Protection Officer and/or legal team will be able to make this call.
If you do not have valid records, not to worry, simply import your users without that consent and they will be automatically prompted to consent by SAP Customer Data Cloud upon their first login post-go live.
Business Rules Considerations
If you’ve ever moved to a new house, then you’ll now that such an event is a perfect opportunity for sorting, cleaning and discarding your stuff, ensuring that your new home only ever gets to see your uncluttered valuables.
An SAP Customer Data Cloud Data Migration is very much that opportunity for your user base, and the perfect time to take a cold hard look at your data and consider whether that user who last logged in 2 years ago is really worth migrating, or if those inconsistently formatted data points have ever brought you any value in the past...
Make sure you involve all key stakeholders and sponsors in this decision and make a point to migrate only users and profile data which make sense for your strategy moving forward.
Any data that has previously been captured about your users without prior consent or evident purpose should be discarded, and this information will greatly contribute to your project team’s task of defining a data schema for your new user base.
An additional scenario where special considerations should be taken is if you are planning to consolidate multiple – previously siloed - user repositories into one, which brings about many complex problems such as overlapping profile data consolidation, credential prioritisation and more… This will be covered in more depth in a future article.
UX & Communication Considerations
There are many variables involved in what, if anything, you are actually going to communicate to your users about this migration. Achieving a completely seamless migration is absolutely possible, but is it your brand's style ? Or more pragmatically, what about all of the changes that might have been implemented ? After all the implementation of SAP Customer Data Cloud often comes with the launch of a rebranded experience, and while it is fine for newly registered users, the experience could be a bit confusing for long time users logging back after the go-live weekend. In this case you could either consider creating a custom campaign in your email marketing system for those users, or alternatively leverage Progressive Profiling methodologies to display a custom welcome screen for migrated users with dedicated call to actions upon their first login. The addition of a simple "isMigrated" boolean flag in your migration could be a neat trick here.
Maybe despite your best effort you could not obtain the necessary info to migrate passwords at all, in which case a password reset campaign should be planned at the time of go live.
Or maybe you consolidated multiple distinct user repositories into one, and for those overlapping users you had to select one password over the other. Proper, temporary calls to actions on the login screen, a small dedicated email campaign, any of these will go a long way to avoid your support team any unnecessary peak of requests (but good preparation of your support team on the new system and processes ahead of time should of course never be skipped).
It is impossible to list every possible scenario of course, but from a generic point of view, always keep in mind how your decisions will affect the end-user experience, and pause to go through all your possible options to address it in the best possible way.
Scoping Considerations: Lite Account vs Full Account
Lite Registration is a way for users to engage with your site and content (such as subscribing to a newsletter) without having to register with a full account, using only their email address and no password. With SAP Customer Data Cloud, those users can later choose to convert their password-less accounts into a fully registered account, to access exclusive member content, place orders, or subscribe to a service.
You may already have been building such a user base within an email marketing system or a CRM for example, in which case it would be a great occasion to import those users in SAP Customer Data Cloud to give them the opportunity to benefit from the full range of experiences you are going to build in your SAP Customer Data Cloud implementation.
As for Full accounts, they are simply user accounts that are associated with a login method, be it a password or social credentials (such as a Facebook account).
The import methods for both types of account differ slightly, and this should be considered when building your migration strategy as identifying those different cases early will avoid any last-minute changes in the development.
Identity Sync vs REST APIs
One of the main decisions for your migration will be whether to use the Identity Sync platform or our set of REST APIs, as this will impact the development time in a major way. Full disclosure; from the point of view of this author this is a really easy decision, 100% of data migration projects led by SAP Services have been completed using Identity Sync due to its ease of use, scalability and flexibility. But the REST APIs remain available (and are in fact used by the very components IdentitySync makes available) and could be the preferred choice of your technical team or implementation partner.
For a short demo of user imports using Identity Sync, take a 6 minute break to watch this micro-learning video:
Password Hashing Algorithms
Another key technical point that was alluded earlier in the article above, is your ability to extract hashed passwords from your legacy database, and whether you have a full understanding of the hashing algorithm used in that legacy platform. This is absolutely critical in order to be able to offer your end users a seamless transition to SAP Customer Data Cloud. This topic is covered at length in Migrating to SAP Customer Data Cloud: Mastering Password Hashing Algorithms
Legacy Social Network Applications
It is surprisingly common to find that the information on who owns social network accounts & application gets lost in a company overtime. But if you already have social login implemented, and you want to migrate your social users and keep their existing authorizations, you will need to setup those same apps in SAP Customer Data Cloud. In the case of Facebook, it will be downright impossible for those migrated users to login without that information. Do yourselves a favor, start questioning your dev team/agency for those credentials now.
Last but not least, you should take a close look at your existing integrations to other systems and how the decisions that you take when migrating your user data might affect those integrations which themselves will likely be ported to SAP Customer Data Cloud. It could be the exclusion of a particular data point which could cause an integration to break, the optional generation of a new unique ID during the migration which could throw those systems out of sync, etc...
A key takeaway should be; you won't be able to predict everything, but by always making sure to inform the right stakeholders of your decisions and keeping the communication going, you will avoid many a pitfall. Your CIAM system doesn't operate in a silo, neither should your project team planning your migration.
This article will hopefully have given you food for thought, kick started a few interesting internal conversations and set you on your way to a successful SAP Customer Data Cloud migration and implementation.
This is just the beginning of the journey, check out the other articles in the series for a deeper dive in this highly important topic: Migrating to SAP Customer Data Cloud.