Migrate from Digital BSS to Pipedrive

Digital BSS Subscriber records map to Pipedrive Person. We extract subscriber_id, msisdn, imei, service_type, plan_name, subscriber_status, and creation_date into Pipedrive custom fields prefixed bss_. The BSS subscriber_id becomes a custom field (bss_subscriber_id__c) rather than the Pipedrive Person ID so that downstream network systems can cross-reference after cutover. Subscriber segment (prepaid/postpaid) maps to a custom single-select field bss_segment__c. IMSI and network credentials do not migrate; these remain in the HSS layer and we document the cross-reference in the network handoff manifest.

Digital BSS Billing Account records map to Pipedrive Organization. We extract account_id, account_name, billing_address, payment_method_ref, credit_limit, outstanding_balance, and ar_status into Pipedrive custom fields bss_account_id__c, bss_balance__c, and bss_ar_status__c. Tax configuration does not transfer because Pipedrive invoicing is CRM-scoped; we flag this in the handoff for the billing team to configure in the OCS layer post-migration. Organization name derives from the billing account name, and the primary contact person is linked via a Person-Organization relationship created after Person migration.

Digital BSS Service Plans and Tariff definitions map to Pipedrive Products. The plan_name becomes the Product name, plan_code becomes the SKU (bss_plan_code__c), and the base recurring price migrates to the Product price field. Bundle allowances, cross-service discounts, and rating rule references are preserved in a long-text custom field bss_tariff_spec__c as JSON-serialized tariff metadata. The OCS rating rules themselves do not migrate because Pipedrive has no charging capability; the tariff spec field documents what the destination OCS must implement.

Digital BSS Order records (activation, plan change, cancellation) map to Pipedrive Deals. Order_id becomes bss_order_id__c, order_type maps to a custom field bss_order_type__c (activation | change | cancellation), order_status maps to the Pipedrive Deal stage, and order_date maps to the Pipedrive close_date. Deal value is set to the prorated recurring charge for plan change orders or zero for pure activations. The Order-to-Deal mapping preserves the full order history timeline. Pending provisioning orders remain open Deals that the operations team closes after the OCS cutover confirms service activation.

Order line items (individual services in a bundle order) map to Deal-Product associations in Pipedrive. The Digital BSS service component name maps to the Product reference, quantity maps to 1 for single-service components, and the component price maps to the line price. Bundle parent relationships are preserved as a custom field bss_bundle_id__c on each line item so the customer can reconstruct bundle groupings in Pipedrive reporting if needed.

Digital BSS Product Catalog hierarchy (parent offerings, child components, add-on services) maps to Pipedrive Products with a parent_product reference stored in bss_parent_catalog_id__c. Bundle constraints and eligibility rules are serialized into bss_catalog_constraints__c as structured text. The catalog tree structure is preserved in a separate catalog-hierarchy export delivered alongside the Pipedrive import so the product manager can reconstruct groupings in Pipedrive's custom reporting or a connected BI tool.

Historical Digital BSS invoices are exported as PDF files and attached to the corresponding Pipedrive Organization or Person record as Note attachments via Pipedrive's file upload API. Invoice line items are not imported as structured records because Pipedrive has no invoice object; open AR balances and last invoice date are captured as custom fields bss_last_invoice_date__c and bss_outstanding_ar__c on the Organization record. Historical invoice PDFs are the system of record for billing disputes post-migration.

Digital BSS operator-specific custom fields (often used for MVNO-specific data like retailer_id, topup_channel, or bundle eligibility flags) are detected during discovery, exported per subscriber and account, and mapped to Pipedrive custom fields of equivalent type. Text fields map to Pipedrive text fields, numeric fields map to numeric fields, and date fields map to date fields. Picklist-equivalent values are mapped to Pipedrive single-select or multi-select fields with the allowed values list built from the Digital BSS enumeration.

Call Detail Records and usage events are not migrated as live Pipedrive records because Pipedrive's data model is not suited for usage history at volume. We export the last-billed usage timestamp per subscriber (bss_last_usage_date__c) and flag the subscriber's usage_status as active, suspended, or churned based on the Digital BSS usage lifecycle. The customer archives full CDR data in a data warehouse or BSS reporting system; we deliver a CSV of last-usage state for reference in Pipedrive.

Digital BSS subscriber owner assignments (the sales rep or customer service agent assigned to a subscriber account) map to Pipedrive User records. We extract owner_id and owner_email from Digital BSS, match by email to the destination Pipedrive User, and set the Pipedrive Person's owner_id to the matched User. Owners without a Pipedrive User match go to a reconciliation queue for the customer to provision before Person import resumes.

Prepaid OCS balance buckets (airtime credit, data credit, SMS credit) have no Pipedrive equivalent. Pipedrive has no balance, wallet, or charging data model. We do not migrate OCS bucket records. Instead, we deliver a balance-shadow manifest: the current bucket state per subscriber at migration cutover, timestamped, in a structured CSV. The operator's OCS team uses this manifest to seed the destination OCS or reconciliation system independently of the Pipedrive migration.

PCRF rules (QoS tiers, data cap policies, fair-use policy triggers) are network-layer configuration with no CRM equivalent. We do not migrate PCRF rules. We extract the raw rule definitions and deliver a PCRF translation manifest in the network handoff document. The operator's network team reviews and rebuilds applicable QoS and data-cap policies in the destination PCRF or OCS platform post-migration.