Migrate from Boostr to Pipedrive

Boostr Advertisers map directly to Pipedrive Organizations. Advertiser name, website, industry, and billing address migrate as Organization fields. We use Advertiser name as the dedupe key during import to avoid duplicate Organizations if multiple Campaigns or Orders reference the same Advertiser. Custom properties on Advertiser migrate to custom fields on Organization using Pipedrive's field type mapping (text, number, date, picklist). Boostr does not have a Contact object separate from Advertiser, so primary contact fields on the Advertiser become Person records linked to the Organization after Org creation.

Boostr Campaigns group multiple Proposals and Orders under a single media campaign umbrella. We preserve Campaign-to-Proposal/Order relationships by creating a Campaign custom field on each Deal in Pipedrive. If the customer has fewer than 50 campaigns and wants active pipeline filtering by campaign, we recommend a separate Campaign Organization with a 'Campaign' label and link Deals via a custom organization-people relationship. The customer chooses the strategy during scoping based on how their sales ops team segments reporting.

Boostr Proposals represent draft offers before an Order is confirmed. We map Proposals to Pipedrive Deals in a 'Proposal' or 'Pending' pipeline stage distinct from booked Orders. Proposal line items migrate as deal custom fields capturing placement, format, dates, impressions, and CPM. Proposal status (Active, Revised, Expired, Accepted) migrates as a custom field; Deals with Accepted Proposals can be flagged for the customer's admin to convert to a separate Order Deal or update the stage during post-migration review.

Boostr Orders are the confirmed commercial agreements representing booked ad inventory. We map Orders to Pipedriver Deals in a 'Booked' or 'Closed Won' stage. Order monetary value, billing status, and payment terms migrate as Deal fields. Boostr's Order-to-Proposal lineage (which Proposal an Order originated from) migrates as a custom Deal field linking the Order Deal to the Proposal Deal by ID reference stored during transformation.

Boostr captures ad inventory as structured line items per Order: placement name, format (display, video, native), flight dates, impressions, CPM, and unit count. Pipedrive's native Deal model is monolithic without standard line-item support, so we extract each inventory unit as a separate group of custom fields on the Deal. For customers with complex product catalogs, we recommend using Pipedrive's Products module: each Ad Inventory Unit type becomes a Product2 record with Standard Price Book entries, and we attach Products to Deals via the Deal-Product relationship. The customer selects the strategy during scoping.

Boostr Revenue Records track revenue at the Order and line-item level with revenue types and billing status. Order-level revenue figures migrate as Pipedrive Deal value (weighted_value and weighted_amount fields). Line-item revenue detail migrates to custom fields on the Deal or to Product pricing on Deal-Product records depending on the inventory mapping strategy selected.

Boostr's configurable pipeline stages (Prospect, Proposal, Negotiating, Booked, etc.) follow a standard media sales lifecycle. We replicate the customer's stage labels, probabilities, and ordering into Pipedrive Pipelines and Stages. Each Boostr pipeline becomes a separate Pipedrive pipeline with its own stage set. Stage probabilities round to Pipedrive's allowed integer format.

Boostr User records including names, roles, team assignments, and email addresses map to Pipedrive Users. We perform an email-based lookup against the destination Pipedrive account's User table to avoid duplicate user creation. Boostr users without a matching Pipedrive User go to a reconciliation queue for the customer's admin to provision before record import resumes.

Boostr supports custom fields on Advertisers, Campaigns, Proposals, Orders, and other objects. We discover the full custom field schema during scoping, map each field to the corresponding Pipedrive custom field by type (text, number, date, picklist, boolean), and apply field-level mapping to the destination. Pipedrive custom field types must match the Boostr source type; we flag any type mismatches during mapping review and document resolution strategy.

Boostr tracks activities manually — reps enter call, email, meeting, and task records by hand rather than automatically. If Boostr contains historical activity records, we migrate them to Pipedrive Activity objects (Activity type maps to Pipedrive activity_type: call, email, meeting, task). Note that Boostr's manual tracking constraint means many accounts have sparse activity history; we validate activity record volume during scoping and adjust migration scope accordingly.

Boostr's GAM (Google Ad Manager) push integration and other connected apps use platform-specific OAuth connections that cannot be replicated in Pipedrive. We document active integrations during discovery and include a reconnection checklist in the post-migration handoff. GAM OAuth reconnection requires the customer to re-authorize the connection in their destination ad ops stack; this is a configuration step, not a data migration task.