Migrate from Boostr to HighLevel

Boostr Advertisers (the buyer accounts in media sales) map to GoHighLevel Contacts. We extract Advertiser name as the Contact's first name or a full name field, and we create a custom field advertiser_company__c to store the advertiser organization name since GoHighLevel Starter has no native Account object. If the Advertiser has multiple contacts, we create a primary Contact record and additional Contact records linked via the original Advertiser ID stored in a custom field. Billing contact roles and advertiser type (agency vs direct) migrate to custom dropdown fields.

Boostr Campaigns (umbrella groupings for proposals and orders) map to GoHighLevel Opportunities. The Campaign name becomes the Opportunity name, and Campaign metadata (channel, flight dates, IO number) migrates to custom Opportunity fields. We preserve the Campaign-to-Proposal and Campaign-to-Order relationships by storing the source Boostr campaign ID in a custom field so the customer can reconstruct the grouping in GoHighLevel if needed.

Boostr Proposals (draft offers before order confirmation) map to GoHighLevel Opportunities in a pre-sale pipeline stage such as 'Proposal Sent' or 'Negotiating'. Proposal line-item pricing, proposed CPM, proposed impressions, and proposed dates migrate to custom Opportunity fields. The Proposal status (Draft, Sent, Accepted, Declined) is stored in a custom field proposal_status__c. We flag that GoHighLevel does not have a native Proposal object, so the lifecycle between Offer and Booking that Boostr models as two objects collapses into a single Opportunity record with a stage transition.

Boostr Orders (confirmed bookings with signed IO) map to GoHighLevel Opportunities in a 'Closed Won' stage. Order revenue, billing status, and actual flight dates migrate to Opportunity amount and custom fields. The Order-to-Proposal relationship (which Order a confirmed booking originated from) is preserved by storing the source Proposal ID in a custom field source_proposal_id__c. This allows the customer's team to see the full lifecycle from proposal to booking in GoHighLevel's activity timeline.

Boostr captures ad inventory as structured line items per order: placement name, format, start/end dates, impressions contracted, CPM rate, and unit count. GoHighLevel has no native line item or product schedule object. We extract each line item as a JSON array stored in a custom text field ad_inventory__c on the Opportunity, with one JSON object per line item. The customer may alternatively request that we create a separate Opportunities custom object in GoHighLevel (available on Unlimited and SaaS Pro plans) for normalized line item records with a lookup to the parent Opportunity.

Boostr tracks revenue at the Order and line-item level. Order-level revenue migrates to the GoHighLevel Opportunity amount field. Line-item revenue disaggregated by placement and format migrates to a custom currency field ad_revenue_detail__c in JSON format matching the line item structure. If the customer requires granular revenue reporting by placement post-migration, we recommend a reporting integration with Google Sheets or a BI tool rather than relying on GoHighLevel's native Opportunity reporting.

Boostr pipeline stages (Prospect, Proposal, Negotiating, Booked, etc.) map to GoHighLevel Opportunity stages. We replicate the customer's stage labels and probabilities into GoHighLevel's pipeline stage configuration. Probability percentages round to whole numbers. If Boostr has more than one pipeline (common in multi-channel media companies), we create separate GoHighLevel Opportunities pipelines for each.

Boostr User records (sales reps, ad ops, admin) map to GoHighLevel User accounts. We perform a name-and-email lookup against the destination GoHighLevel workspace's user table. Any Boostr User without a matching GoHighLevel User is flagged in the reconciliation report for the customer's admin to provision before record import. Inactive Boostr users become inactive GoHighLevel users so that historical owner attribution is preserved.

Boostr supports custom fields on Advertisers, Campaigns, Orders, and Proposals. We discover the full custom field schema during scoping, map each field to a GoHighLevel custom field of equivalent type (text, number, date, dropdown, checkbox), and include all custom fields in the mapping specification before transformation begins. GoHighLevel custom field naming follows their internal conventions; we handle the API name generation during the GoHighLevel field creation phase.