Migrate from Gamooga to Salesforce Sales Cloud

Gamooga User profiles (email, mobile number, behavioral attributes) map to Salesforce Contact as the primary CRM record. Standard profile fields migrate directly. Extended properties uploaded via Gamooga's Historic Data Push migrate as custom fields on Contact with the __c suffix. We preserve the Gamooga user_id in a custom field gamooga_id__c for reconciliation. Salesforce requires a non-null LastName on Contact, so we derive this from the display name or email local-part when not explicitly available in Gamooga.

Gamooga users in a pre-customer lifecycle stage (subscribers, trial users) may map to Salesforce Lead instead of Contact depending on the customer's lifecycle model. We determine the mapping during scoping based on whether the Gamooga user has converted to a customer or remains in an acquisition-stage status. The gamooga_id__c custom field is also created on Lead for reconciliation.

If Gamooga contains company-level records or domain-associated user groupings, these map to Salesforce Account. The domain becomes the Account Website field. Account is created before Contact import so the AccountId lookup is satisfied at the moment of Contact insert. If Gamooga does not maintain company records, we create Account records from user-domain groupings during migration.

Gamooga Campaigns (lifecycle and promotional journeys) map to Salesforce Campaign objects. Campaign Name, Status, Type, and dates migrate directly. Channel-specific configuration (push template IDs, SMS sender IDs) cannot migrate because these are Gamooga channel bindings; we document them as configuration stubs requiring rebuild in Salesforce Marketing Cloud or Marketing Cloud Account Engagement.

Gamooga dynamic Segments use behavioral rules (demographics, purchase history, app behavior, geolocation) evaluated in real time by the Gamooga engine. These rule definitions cannot be exported as portable configuration. We extract the rule structure as human-readable criteria for each segment and reconstruct them in Salesforce as Campaign filter-based audience lists using the Campaign Members feature. Any behavioral data attributes present in Gamooga but absent from the Salesforce Contact schema are flagged as schema gaps requiring custom field creation before segment reconstruction completes.

Gamooga Events (page views, purchases, cart actions, custom behavioral events) map to Salesforce Task and Event activity records. Event type maps to Task Subject or Event Subject; event timestamp maps to ActivityDate and StartDateTime respectively. The WhoId on Task points to the migrated Contact or Lead. Large event histories (over 100,000 records) require Salesforce Bulk API 2.0 with chunking and parent-record lookup resolution to avoid timeout and governor limit failures.

Extended user properties uploaded via Gamooga's Historic Data Push migrate as custom Contact or Lead fields in Salesforce. Data type mapping follows standard conventions: strings become Text, dates become Date, numbers become Number, and booleans become Checkbox. Ambiguously typed fields (raw JSON blobs, mixed-type arrays) are flagged for customer review during scoping, and either are cleaned during transformation or are stored as Long Text Area fields.

Gamooga Campaigns that represent sales-oriented revenue journeys (closed-lost, closed-won, pipeline progression) may map to Salesforce Opportunity records. We identify these during discovery by reviewing campaign status values and whether revenue data is attached. The mapping is conditional and requires customer confirmation during scoping; not all Gamooga Campaigns are sales-pipeline records.

Gamooga workflow definitions created on the graphical canvas are documented as structured step sequences in a written handoff document. Channel-specific action steps (push template bindings, SMS sender bindings) are documented as configurable stubs. We do not migrate workflows as executable Salesforce Flow because the automation models differ structurally. The customer's admin or a Salesforce partner rebuilds them post-migration.

Gamooga Owners (users who own campaigns, segments, or user records) map to Salesforce User records by email match. Any Gamooga Owner without a matching Salesforce User is held in a reconciliation queue for the customer's admin to provision before record import resumes. OwnerId references are required on most standard objects, so this step gates the full migration.

Gamooga pre-built analytics dashboards export as static data files (CSV or Excel) rather than live Salesforce Reports. The underlying live-reporting pipeline, real-time segment calculations, and predictive recommendation outputs cannot transfer. We deliver the static export files and a mapping document showing which Gamooga report metrics correspond to standard Salesforce Report types.

Gamooga's dynamic recommendation engine is platform-native and tied to its predictive analytics layer. Recommendation logic and model outputs do not export and must be rebuilt in Salesforce using either Salesforce Data Cloud for behavioral scoring or a third-party recommendation engine. We document the recommendation model inputs (user attributes, event types, product attributes) as a rebuild specification.