Migrate from Boostr to Zoho CRM

Boostr Advertisers — the buyer organizations in the media sales data model — map directly to Zoho CRM Accounts. Advertiser name becomes Account Name; billing address, contact information, and industry tags migrate to corresponding Account fields or custom fields. We extract the Advertiser's associated contact records from Boostr and attach them as Zoho Contacts linked to the parent Account via the Account Name lookup. If the customer has Advertisers with no named contacts (house accounts), we create a minimal Account record and flag it for contact expansion post-migration.

Boostr Campaigns group multiple Proposals and Orders under a single media campaign umbrella. We map Campaign records to Zoho CRM Campaigns, preserving Campaign type, status, start and end dates, and budget. The Campaign-to-Proposal relationship is documented as a Zoho Campaign Member lookup so that Proposals (as Deals) can be linked back to the originating Campaign. Note that Zoho Campaigns are marketing campaign records and do not automatically associate with Deals without manual linking or a custom field bridge.

Boostr Proposals (draft offers sent to advertisers before order confirmation) map to Zoho Deals in a pre-closed stage. We create a Proposal stage in the Zoho pipeline — typically 'Proposal Sent' or 'Negotiation' — and set the probability to match Boostr's Proposal probability. Proposal-line-item pricing, proposed CPM, proposed impressions, and proposed dates migrate to custom fields on the Deal (e.g., prop_cpm__c, prop_impressions__c) because Zoho Deals do not natively support line items. The Proposal-to-Order lineage is preserved via a custom text field holding the Boostr Order ID once the Proposal converts.

Boostr Orders — confirmed commercial bookings — map to Zoho Deals in the 'Closed Won' stage. The Order total revenue maps to Deal Amount. Order status (Active, Completed, Cancelled) maps to a custom picklist field order_status__c on the Deal. Because Boostr separates Proposals and Orders as distinct objects, a single Advertiser may have multiple Deal records representing both open Proposals and closed Orders; we preserve this distinction by stage and do not collapse them into a single Deal record.

Boostr captures sellable ad units (placements, formats, impression volumes, CPM rates, flight dates, channel) as structured line items attached to an Order. Zoho CRM has no native Deal line-item object, so we create a custom Ad Inventory module with lookup relationships to Deals. Each inventory unit becomes a record in this module, linked via the parent Deal's Zoho ID. Fields include placement_name__c, ad_format__c, channel__c, impressions__c, cpm__c, start_date__c, end_date__c, and unit_count__c. If the customer has fewer than 500 inventory unit records, we load them as individual custom module records; for bulk scenarios we discuss a compressed custom field approach with the customer during scoping.

Boostr tracks revenue at the Order and line-item level with revenue type and billing status. Order-level revenue maps directly to Zoho Deal Amount. Line-item revenue (impressions multiplied by CPM) is stored in the custom Ad Inventory module's computed revenue field (impressions__c × cpm__c). Billing status migrates to a custom picklist billing_status__c on the Deal. Historical revenue records not attached to a specific Order are documented for admin reconstruction in Zoho Reports.

Boostr's configurable pipeline stages (Prospect, Proposal, Negotiating, Booked, etc.) are replicated in Zoho CRM as pipeline stages under the customer's chosen Zoho pipeline. We match stage labels from Boostr to Zoho stage names, preserving probability percentages and stage ordering. Boostr's 'Booked' stage maps to Zoho Closed Won; any Lost stage maps to Zoho Closed Lost with a loss reason custom field.

Boostr User records — including name, email, role, and team assignment — map to Zoho CRM Users. We resolve by email address match during import. Any Boostr User without a matching Zoho User is placed in a reconciliation queue for the customer's Zoho admin to provision before record import resumes. Inactive Boostr users are imported as inactive Zoho Users so historical assignment is preserved.

Boostr supports custom fields on Advertisers, Campaigns, Orders, and other objects. We discover the full custom field schema during scoping by reviewing a Boostr export file, then create equivalent custom fields in Zoho CRM before data loads. Field type mapping is direct for text, number, date, and picklist fields; multi-select picklists in Boostr map to Zoho multi-select picklists; checkbox fields map to Zoho checkboxes. Any Boostr custom field without a clear Zoho equivalent is documented for admin review and either mapped to a custom field or dropped with an explicit notation.

Boostr's Google Ad Manager push integration uses platform-specific OAuth tokens that cannot be replicated in Zoho CRM. We document the active GAM connection during discovery (account ID, integration scope, sync direction) and include a reconnection checklist in the post-migration handoff. The customer's ad ops team re-establishes the OAuth connection in their ad ops stack independently post-migration. No integration data — including GAM order IDs — migrates into Zoho CRM as part of the standard data scope.