Migrate from MobileAction to Odoo CRM

MobileAction Tracked Apps map to Odoo res.partner records in Company mode. App ID becomes a custom field app_store_id__c on the partner, app name becomes the partner display name, and store type (App Store or Google Play) becomes a selection field. Visibility score and estimated download counts from MobileAction become custom float fields on the partner. We resolve the partner as the parent record before any keyword or benchmark imports because Odoo requires the res.partner record to exist before related models (ranking_history, competitor_benchmark) with Many2one relationships can reference it.

Keyword tracking data from MobileAction (keyword text, country, search volume estimate, difficulty score, traffic estimate) maps to a custom Odoo model mobileaction.keyword created during migration scope. The keyword model has a Many2one relationship to res.partner (the tracked app). Search volume and difficulty are third-party modeled values — we store these as float fields with an estimation_source__c char field set to 'MobileAction modeled' so downstream analysts can apply their own confidence weighting. Keyword text maps as a Char field with an index for search.

Daily or weekly ranking snapshots per keyword-app-country pair become dated records in the custom mobileaction.ranking_history model. Each record links to mobileaction.keyword (Many2one), stores the date as a Date field, and stores the rank position as an Integer field. This is a high-volume dataset — we chunk exports into monthly batches and use Odoo's ORM batch insert with commit every 5,000 rows to avoid memory exhaustion during import.

Competitor visibility scores and ranked keyword lists export from MobileAction into a custom mobileaction.competitor_benchmark model. The model stores the competitor app name, store, visibility score, and ranked keyword associations. The user-curated competitor set is preserved as a named group in a char field competitor_set__c so the competitive framing transfers even though Odoo has no native competitor tracking. We flag any competitor app IDs that were no longer retrievable from the MobileAction API at export time.

Apple Search Ads campaign structures (campaign name, status, budget, ad groups, keyword assignments) map to an Odoo project.project record if the customer uses Odoo Project, or to a custom mobileaction.campaign model if they do not. Goal configurations and automated bid rules from SearchAds.com are exported as structured JSON and stored in a campaign_config__c field as a reference document — we do not replicate SearchAds automation logic in Odoo because Odoo Workflow and Studio have a different action model. The campaign is linked to the tracked res.partner app via a Many2one field.

CPP metadata (page ID, associated keywords, screenshot URLs, promotional text, video URL) migrates as a combination of ir.attachment records for the visual assets and custom Char/Text fields on the res.partner record for the page metadata. Screenshot and video URLs are re-hosted during migration because MobileAction asset URLs are retired upon account cancellation — we flag this in the gotchas section. The page ID and associated keywords store as Char and Text fields on the partner.

Creative asset references (screenshot ID, video URL, impression share, performance signals) from MobileAction export as URL references plus metadata fields. We store these as ir.attachment records linked to the mobileaction.campaign record, with performance metrics in custom Float/Integer fields on the attachment. Raw creative binary files are not available in MobileAction's Dashboard API — only URL references exist, so we re-host these during migration before the source URLs expire.

Estimated downloads, revenue projections, and market share figures from MobileAction's App Intelligence module become custom Float fields on the res.partner record (estimated_downloads__c, estimated_revenue_usd__c, market_share_pct__c). All three values carry an estimation_provenance__c tag set to 'MobileAction third-party modeled' to ensure analysts understand the data quality constraints. We do not treat these as first-party financial records.

SearchAds.com automated bid and budget rules are exported as structured condition sets with their goal category, threshold values, and action types. Odoo does not have a native Apple Search Ads automation layer, so we do not migrate these as executable logic. Instead, we deliver a structured CSV and PDF inventory of every automation rule with its trigger, conditions, actions, and recommended Odoo Studio equivalent (e.g., a scheduled action that updates campaign budget fields based on threshold conditions). The customer's Odoo admin rebuilds these in Odoo Workflow or Studio post-migration.

User-level settings from MobileAction (tracked countries, notification preferences, team member assignments, report schedule) export as a configuration blob per user. We parse this into a structured CSV and store it as a res.config.settings reference document in the customer's shared drive or as a note on the relevant res.partner or project.project record. Odoo has its own settings architecture (res.config.settings), so these migrate as documentation for manual configuration rather than a direct schema translation.

MobileAction user accounts referenced on tracked apps, campaigns, and keyword exports map to Odoo res.users records by email match. We extract the owner ID from each MobileAction entity and resolve it against the Odoo User table. Any MobileAction owner without a matching Odoo user goes to a reconciliation queue for the customer's admin to provision before the migration record import resumes.

Apple Search Ads campaign hierarchies (campaign, ad group, keyword assignments) map to Odoo project.project as a parent record with task records representing ad groups. The project structure allows Odoo-native reporting on campaign status. We configure the project as a non-billable project type and add custom fields for campaign budget, status, and search ads goal category. Ad group keyword assignments become Odoo task records with description fields containing the keyword list.