Gigya (SAP) Migration Guide

Overview

Gigya (now part of SAP Customer Data Cloud) is a customer identity and access management platform that handles user authentication, profile management, and social login.

Migration Strategy

There are two main types of migration supported:

Migration Type	Managed By	Timing
Bulk Migration	LoginRadius	One-time migration before go-live
Just-in-Time (JIT)	Customer	Gradual (1–6 months), based on business needs

Bulk Migration (One-Time Import)

Bulk migration is a one-time process handled entirely by the LoginRadius migration team. Using Gigya's Search API, LoginRadius fetches user records in batches and imports them into your LoginRadius.

Required Configuration

The following parameters must be provided to initiate the bulk import:

Field	Description	Example / Value
`apiKey`	Your Gigya API key	`<ApiKey>`
`secret`	Your Gigya secret key	`<Secret>`
`site`	Optional site name for multi-site setups	`AEnetworks`
`datacenter`	Gigya data center	`us1`, `eu1`
`ssl`	Enable secure SSL connection	`true`/`false`
Rate Limit	Maximum allowed API requests to Gigya Search API	`<Rate Limit>`

Data Mapping Table

You’ll need to supply a data mapping between Gigya fields and LoginRadius fields for a smooth import. Below is a sample mapping:

Gigya Field	LoginRadius Field
`isVerified`	`EmailVerified`
`isActive`	`IsActive`
`UID`	`Uid`
`profile.email`	`UserName`
`profile.firstName`	`FirstName`
`profile.lastName`	`LastName`
`loginIDs.emails`	`Email.Primary`
`loginIDs.unverifiedEmails`	`UnverifiedEmail.Secondary`
`identities.country`	`Country.Code`
`profile.state`	`State`
`created`	`CreatedDate`
`lastUpdated`	`UpdatedTime`
`lastLogin`	`LastLoginDate`
`password`	`Password`
`profile`	`Addresses1`
`data.terms`	`CustomFields.terms`
`data.register_referer_url`	`CustomFields.register_refer_url`
`data.register_site`	`CustomFields.register_site`

You must confirm all mappings during the migration setup phase. This includes both standard and any custom or additional fields you may be managing, which can also be mapped to the appropriate LoginRadius fields.

Password Hash Types

Gigya stores user passwords in various formats such as MD5, PBKDF2, SHA1, etc..

LoginRadius supports most formats, but the exact hash type and salt usage must be provided to configure password validation correctly.

LoginRadius can also migrate social identities. This involves:

Extracting the identities array from each Gigya user profile.
Mapping social providers to the LoginRadius format.

Bulk Migration Rate Limits

Platform	API	Rate Limiting
Gigya	Search API	Subject to SAP CIAM limits

Bulk Migration Key Points

This is a one-time operation before your LoginRadius project goes live.
Includes all active and verified user data.
Passwords (MD5, PBKDF2, etc.) are migrated as-is.
Optional support for social identities.
LoginRadius handles data transformation and API rate limiting.

Just-in-Time (JIT) Migration

The customer team is responsible for JIT migration, which occurs during user login or registration. It’s useful for gradually moving active users without migrating everyone at once.

Key Features

Occurs at the time of user login or registration.
Does not interrupt the user experience.
Gradual migration over 1 to 6 months, depending on business goals.
Ideal for large databases with inactive or infrequent users.

Implementation Steps for Just-In-Time (JIT) Migration

API based JTI Migration
Orchestration-Based JIT Migration

Steps for Just-In-Time (JIT) Migration using the API

This JIT migration approach enables users to transition seamlessly from Gigya to LoginRadius without needing to reset their passwords, ensuring a smooth and transparent login experience.

When a user attempts to log in:

First, check if the user already exists in LoginRadius using one of the following APIs (based on identifier):
- Email: Check Email Availability
- Username: Check Username Availability
- Phone Number: Check Phone Number Availability

2. If User Exists in LoginRadius

Proceed with the standard LoginRadius authentication flow using:

3. If the User Does Not Exist in LoginRadius

Authenticate the user against Gigya using their provided credentials (email/username and password) via the Gigya API:
Gigya Authentication API Docs

Upon successful authentication, retrieve the user profile including:

Email
First Name
Last Name
Custom Attributes (if any)

4. Create a User in LoginRadius

If Gigya authentication succeeds:

Use the LoginRadius Account Create API to register the user.
Include:
- User identity (email/username/phone)
- Password (the one provided during login)
- Additional profile fields retrieved from Gigya

Note: This API requires your API Secret and should only be called securely from your backend.

5. Authenticate User in LoginRadius

After creating the user in LoginRadius, log them in using the same password they initially provided:

This ensures a seamless experience—the user won't even notice they were migrated.

6. If Password Validation Fails in Gigya

If Gigya doesn't validate the credentials:

Prompt the user to:
- Retry login, or
- Reset their password via LoginRadius:
  - Forgot Password
  - Send a reset link to the user’s email
Once they receive the reset link:
- Validate it using the Reset Password by Token
- Allow them to set a new password

7. Future Logins

From this point on:

The user is fully managed by LoginRadius.
All future authentication and profile operations will be handled exclusively via LoginRadius.

Note: Ensure all API calls involving secrets are made securely from your backend infrastructure.

Rate Limit Overview

Platform	API	Rate Limiting
LoginRadius	Account/Auth APIs	Based on your LoginRadius Acceptable Use Policy

Requirements for JIT Migration

To implement JIT migration, you’ll need:

Your LoginRadius API Key and Secret
A script or middleware that:
- Intercepts the login flow
- Pulls user data from Gigya
- Transforms and pushes the data into LoginRadius
Error handling for:
- Rate limits
- Password standards.