Migrate from Gamooga to Odoo CRM

Gamooga User profiles map directly to Odoo CRM Contact records. Standard profile fields (email, mobile number, name) migrate to the corresponding Contact fields. Custom behavioral attributes uploaded via Historic Data Push migrate as custom Contact fields, preserving data type where identifiable and flagging any ambiguous typed fields. We resolve email as the dedupe key during import to prevent duplicate Contact records.

Gamooga Campaigns representing lifecycle or promotional journeys map to Odoo CRM Opportunity records. Campaign status, name, and description migrate to Opportunity fields; channel-specific configuration (push template IDs, SMS sender IDs) cannot migrate and becomes configurable stubs in Odoo CRM that the admin completes post-migration. Parent campaign hierarchies map to a custom parent_campaign_id field.

Gamooga dynamic Segments use behavioral rules (demographics, location, purchase history) evaluated in real time. These rule definitions cannot be exported as portable configuration. We extract the segment rule structure as human-readable criteria and reconstruct equivalent filters in Odoo CRM using domain filters and/or static Groups. We flag any behavioral data attributes present in Gamooga but absent from the destination Contact schema, noting which ones require custom field creation.

Gamooga Events (page views, purchases, cart actions) that triggered automations export as activity history. We map event types to Odoo CRM mail.message records or note.log entries linked to the corresponding Contact. Event timestamps and behavioral metadata (product IDs, page URLs, cart values) migrate to custom fields on the activity record. High-volume event streams may require sampling or summary aggregation to stay within Odoo API rate limits.

Pre-built Gamooga analytics dashboards and real-time insights export as static data snapshots. The underlying live-reporting pipeline does not transfer. We export available dashboard exports as CSV and attach them to the relevant Odoo CRM record, or deliver them as a structured data file for manual reference. Native Odoo CRM reporting is reconstructed by the customer admin post-migration.

Gamooga workflow definitions on the graphical canvas migrate as structured step sequences in a written inventory document. Channel-specific action steps (push template bindings, SMS sender configurations) migrate as configurable stubs requiring admin completion. Odoo CRM automation rebuilt from this inventory is outside the migration scope and is handled by the customer admin or an Odoo implementation partner.

Gamooga Channels (Push, SMS, Email, In-App, Web Push) are platform-native delivery infrastructure and do not export. We migrate the audience intent and content metadata but not channel credentials, sender IDs, or template configurations. These are reconfigured by the customer admin in Odoo CRM or a connected marketing app post-migration.

Gamooga's dynamic recommendation engine is platform-native and tied to its predictive analytics layer. Recommendation logic and model outputs do not export. We document the recommendation triggers and use cases observed in the Gamooga configuration for the customer to evaluate Odoo apps or third-party recommendation tools post-migration.

Gamooga Owners referenced on User, Campaign, and Segment records resolve by email match against Odoo CRM User records. Any Gamooga Owner without a matching Odoo CRM User is held in a reconciliation queue for the customer admin to provision before record import resumes.

Extended user properties uploaded via Gamooga Historic Data Push migrate as custom Contact fields in Odoo CRM. We infer data type (string, integer, date, boolean, selection) from the property structure where available and flag any ambiguous typed fields for the customer admin to validate and correct post-migration. Field API names follow Odoo nomenclature with x_ prefix for custom fields.

If Gamooga captured inbound leads via forms or web tracking that were stored as User records with a lead-type tag, we migrate those as Odoo CRM Lead records instead of Contact records. We use a tag or custom field discriminator during scoping to identify which Users should land as Leads versus Contacts.

Gamooga User profiles may contain company affiliation data (company name, domain) that maps to Odoo CRM Account records. We extract unique company names from User profiles, create Account records, and link the corresponding Contacts to the Account via partner_id lookup. This creates the Account-to-Contact hierarchy that Odoo CRM reporting relies on.