Migrate from Digital BSS to Freshsales

Digital BSS Subscriber records carry nested properties for service type, plan assignment, subscriber status, and billing identifier. We map these to Freshsales Contact records, preserving the subscriber ID as a custom field bss_subscriber_id__c, service type as a picklist custom field, and status as a custom field mapping to Freshsales' Contact status values. We create the Contact before any child record import so that lookups are satisfied at insert time. IMSI and HSS credentials do not migrate because Freshsales has no network credential fields and those records require network-layer re-provisioning outside CRM scope.

Digital BSS Service Plans include rating rules, chargeable event definitions, and bundle allowance formulas that have no direct Freshsales equivalent. We map each plan to a Freshsales Product record with plan name, plan code, and monthly charge stored as standard price fields, and we attach the full rating rule definition as a JSON-formatted note or as custom fields (bundle_data_units__c, voice_minutes__c, sms_count__c) to preserve the plan structure for the product team to review. The customer decides during scoping whether to treat each plan as a standalone Product or as a Product2 entry with bundle metadata attached.

Digital BSS Billing Accounts link subscribers to payment methods, invoicing preferences, and AR records. We map account balances and credit limits to Freshsales Account fields, with payment method details stored as custom fields (payment_method_type__c, credit_limit__c, ar_balance__c). Tax configuration does not transfer because Freshsales does not carry telecom tax jurisdiction rules; we flag tax configuration as requiring rebuild in the destination's billing or accounting module. Open AR balances are flagged during pre-migration reconciliation and must be cleared or explicitly carried as a credit note before cutover.

Digital BSS Product Catalog defines offer eligibility, bundle constraints, and plan-to-product relationships that form a hierarchical tree. Freshsales Products are flat entries without native hierarchy. We create a Freshsales Product for each catalog offer and a custom object bss_catalog_hierarchy__c to store the parent-child relationship, eligibility rules, and constraint flags as custom fields. The product team reviews the catalog manifest during the migration window and configures the Freshsales product relationships accordingly before go-live.

Prepaid OCS balance buckets carry live monetary value and must not lose precision during migration. We create a custom object bss_ocs_bucket__c in Freshsales with fields for subscriber ID (lookup to Contact), bucket type (airtime, data, SMS, cross-service credit), current balance, currency, last_updated timestamp, and expiry date. We perform a two-phase cutover: all bucket records are written to Freshsales and verified against the source total before the destination OCS begins serving those balances. Any bucket with a discrepancy above a configurable threshold (default $0.01 or equivalent) is flagged for manual resolution before cutover proceeds.

Digital BSS Order records for plan activations, plan changes, and service cancellations map to Freshsales Deal records. We preserve order number as deal name, plan type as a custom field, order status as a stage value, and order creation date as ActivityDate. The operator's deal pipeline in Freshsales must be configured before migration to represent the relevant lifecycle stages (Activations, Upgrades, Cancellations, Churn). We map the pipeline stages to Freshsales Deal stages during the schema design phase.

Call Detail Records and usage events from Digital BSS are typically archived rather than migrated live because Freshsales has no real-time usage rating engine. We extract the last-billed usage timestamp per subscriber and write a bss_usage_record__c custom object record capturing the last usage date, total voice minutes, total data bytes, total SMS count, and billing period end date. This establishes billing continuity and prevents a gap in the usage timeline when the new BSS OCS takes over rating responsibility.

Historical invoices from Digital BSS migrate as bss_invoice__c custom object records, including invoice number, invoice date, line items (stored as a long text field or related list entries), total amount, currency, payment status, and open AR flag. PDF invoices are exported separately and attached to the invoice record via Freshsales file attachments. Open AR balances must be reconciled and cleared or explicitly carried as a credit balance before cutover so that the new BSS does not attempt to re-bill already-paid amounts.

Digital BSS frequently carries operator-specific custom fields for data not represented in the standard BSS schema. We detect all custom field definitions during the discovery phase, export their values per subscriber, account, or order, and map them to Freshsales custom fields of the matching data type (text, number, date, picklist, checkbox). We require the customer to confirm the target field types during schema design because Freshsales enforces type consistency at the field level. Any custom field whose data type cannot be represented in Freshsales is documented in the mapping manifest with a recommended workaround.