Migrate from Boostr to Salesforce Sales Cloud

Boostr Advertisers are the buyer accounts in the media data model, roughly equivalent to Companies/Accounts in Salesforce. We map Advertiser fields (company name, industry, address, contact information) to Salesforce Account fields and use Advertiser name as the dedupe key. Custom properties on the Advertiser (such as agency relationships, advertiser type, or billing terms) map to Salesforce custom fields on Account. Boostr Advertiser status (Active, Inactive) maps to an Account custom field since Salesforce does not have a native account status object.

Boostr Campaigns group multiple Proposals and Orders under a single media campaign umbrella. We preserve Campaign-to-Proposal and Campaign-to-Order relationships by mapping Campaign metadata to Salesforce Campaign and storing cross-reference IDs in custom fields on the linked Opportunities. Campaign start and end dates, budget, and targeting notes map to Campaign StartDate, EndDate, BudgetedCost, and custom description fields.

Boostr Proposals are distinct from Orders — a Proposal represents an offer sent to the advertiser before an order is confirmed. We map Proposals to Salesforce Opportunity with a custom stage value (Proposal or Prospecting) and preserve the proposal-line-item pricing as custom fields or in a custom Proposal Line Item object. The Proposal-to-Order relationship is stored as a custom field on the Opportunity for audit. Boostr Proposal status (Draft, Sent, Revised, Accepted, Declined) maps to a custom Opportunity status field since Salesforce stage names are not granular enough to capture this lifecycle.

Boostr Orders are the booked, confirmed commercial agreements — the core transactional record in Boostr's OMS. We map Orders to Salesforce Opportunity in a Closed Won stage with the Order number stored as a custom Opportunity field and Order date stored as CloseDate. The Order-to-Advertiser relationship maps to Opportunity AccountId. If the customer also has a Proposal record linked to this Order, we preserve that reference via the custom Proposal field on the Opportunity.

Boostr captures ad inventory as structured line items per Order — placement, format, dates, impression target, CPM rate, and unit count. Salesforce Opportunity does not natively support nested line-item hierarchies. We design one of two strategies during scoping: (a) a custom Ad_Inventory_Item__c object with a lookup to the parent Opportunity and fields for placement, format, start_date, end_date, impressions_target, cpm, units, and total_revenue, or (b) a flattened set of custom fields on the Opportunity itself. The choice depends on the customer's line-item volume and reporting needs. We document the chosen strategy in the mapping spec.

Boostr tracks revenue at the Order and line-item level. Revenue figures, revenue type (Gross, Net, Agency), and billing status migrate to Opportunity Amount (standard) and custom revenue type and billing status fields. For multi-line Orders, we sum line-item revenue into the Opportunity Amount and store the breakdown in the custom Line Item object. Revenue dates migrate to Opportunity CloseDate or custom billing period fields.

Boostr's configurable pipeline stages (Prospect, Proposal, Negotiating, Booked, etc.) follow a standard media sales lifecycle. We replicate the customer's stage labels and probabilities into Salesforce Opportunity StageName and StageProbability. Stage mapping is validated in Sandbox before production migration begins. If Boostr uses a multi-stage workflow that does not map cleanly to Salesforce's flat stage list, we use a custom Opportunity status field to capture the additional granularity.

Boostr User records including names, roles, and team assignments map to Salesforce User by email match. Any Boostr User without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Boostr's role hierarchy maps to Salesforce Role hierarchy if the destination org uses roles for territory management.

Boostr supports custom fields on Advertisers, Campaigns, Orders, and other objects. We discover the full custom field schema during scoping, including any custom field types (text, number, date, picklist, checkbox). Each custom field maps to a Salesforce custom field of the equivalent type. Boostr custom fields with agency relationships, billing terms, or media category tags become Account custom fields. Custom properties that apply to Orders become Opportunity or custom Line Item custom fields depending on the chosen line-item strategy.

Boostr Order-level custom fields (such as billing terms, insertion order references, or third-party trafficking notes) map to Opportunity custom fields. Line-item-level custom properties map to the custom Line Item object's custom fields. We pre-create the destination schema — including all custom fields, field-level security, and validation rules — in a Salesforce Sandbox before any data import begins.

Boostr's GAM (Google Ad Manager) push integration and any other OAuth-connected apps are platform-specific connections that cannot be replicated in Salesforce. We document the active integrations during discovery (including OAuth scopes, GAM property IDs, and sync direction) and include a reconnection checklist in the post-migration handoff. The customer must re-establish these OAuth connections in their ad ops stack post-migration. This is not a data migration issue but a configuration step that must be planned for separately.

Boostr's manual activity logs (calls, meetings, tasks entered by reps) migrate to Salesforce Task and Event records. Because Boostr does not automatically capture engagement history, the volume of historical activities depends on how consistently reps entered data. We extract Boostr activity records by date range during the CSV export session and map them to Salesforce Task (for calls and tasks) and Event (for meetings) with WhoId and WhatId resolved to the migrated Account or Opportunity.