Migrate from Digital BSS to Salesforce Sales Cloud

Digital BSS Subscriber records map to Salesforce Account (for billing and enterprise-level records) and Contact (for individual subscriber records). The subscriber's service type, plan assignment, status, and balance reference migrate to custom fields on Account (bss_subscriber_id__c, bss_plan_id__c, bss_status__c) and Contact (bss_balance__c, bss_service_type__c). IMSI and MSISDN from the AAA/HSS layer map to custom Contact fields for network authentication reference. We preserve the source Subscriber ID as a dedupe key and cross-reference field.

Digital BSS Service Plans include rating rules, chargeable events, and bundle allowances. We map each tariff plan to a Salesforce Product2 record with custom fields capturing voice_minutes__c, data_allowance_mb__c, sms_count__c, and bundle_constraints__c. Rating rules (per-second billing, peak/off-peak rates) do not migrate as executable logic; we document them in a Plan Definition Reference attached to the Product2 record for the billing team's review. Prepaid and postpaid plan designations map to a custom plan_type__c picklist.

Digital BSS Billing Accounts link subscribers to payment methods, invoicing preferences, and AR records. We map account balances and credit limits to custom fields on the Salesforce Account (bss_ar_balance__c, bss_credit_limit__c, bss_payment_method__c). Tax configuration does not migrate because tax rules are destination-jurisdiction-specific; we flag the original tax configuration for the customer's finance team to rebuild in Salesforce Tax Settings or a connected tax engine. Invoicing preferences map to Account fields for billing address and billing cycle.

Prepaid balance buckets are critical real-time records with live monetary value. We create a custom OCS_Balance__c object with fields for subscriber_reference__c (lookup to Contact), bucket_type__c (voice/data/SMS/combined), balance_amount__c, currency__c, last_updated__c, and expiry_date__c. Cutover uses a two-phase write: first we write all bucket records to a shadow object and verify counts against the source, then after sign-off we activate the balances for live serving. This prevents double-spending during the migration window. We flag any bucket with a negative or null balance for manual resolution before cutover.

Call Detail Records and usage events are typically archived rather than migrated as live records. We extract the last-billed usage date per subscriber and set it as last_billed_usage_date__c on the Contact record to ensure no gap in rating when the new system goes live. For regulatory or billing dispute purposes, we export CDRs as a structured CSV archive and attach it to the Account as a ContentDocument. We do not replay historical CDRs into Salesforce Activities because the CRM is not a billing engine.

The Digital BSS product catalog defines which services are offerable, with relationships to plans, pricing, and bundle constraints. We extract the full catalog tree and map it to Salesforce Product2 records with the product hierarchy preserved in a parent_product__c lookup. Pricing rules map to StandardPriceBook entries. Bundle constraints (mandatory add-ons, mutual exclusivity, capacity limits) are documented as custom fields on the Product2 record (bundle_constraints__c, required_addons__c) for the product manager to rebuild in Salesforce CPQ if quoting complexity requires it.

PCRF policy rules govern QoS, data caps, and policy enforcement and use vendor-specific syntax that does not port between BSS platforms. We export all PCRF rule definitions from Digital BSS as structured records in a custom PCRF_Rule_Manifest__c object with fields for rule_name__c, condition_logic__c, qos_profile__c, data_cap_mb__c, and source_xml__c. The operator's network team reviews and rebuilds these rules against the destination PCRF or policy engine. This manifest is a handoff artifact, not a migrated working rule set.

Authentication, Authorization, and Accounting records plus Home Subscriber Server data manage device-level and subscriber-level network access. We map subscriber IMSI, authentication credentials (hashed), and device identifiers to custom fields on the Salesforce Contact record (imsi__c, auth_algorithm__c, device_id__c, hss_realm__c). Final network-side provisioning requires the operator's HSS team to activate these credentials in the destination HSS; we provide the credential payload but do not execute HSS provisioning.

Order records for plan activations, changes, and cancellations map to Salesforce Order records if the destination org includes Order Management. Subscription records for recurring service provisioning map to a custom Subscription__c object with fields for subscriber_reference__c, plan_product__c, start_date__c, end_date__c, and status__c. Order history and status timestamps preserve for audit and billing dispute resolution. If the customer uses Salesforce Subscription Management (part of Revenue Cloud), we map to the standard Subscription object instead.

Historical invoices export as PDFs or structured records from Digital BSS. We map invoice line items to a custom Invoice__c object with fields for invoice_number__c, invoice_date__c, total_amount__c, and status__c, and attach the original PDF to the Account as a ContentDocument via ContentDocumentLink. Open AR balances flag for reconciliation before cutover so that no outstanding receivable is orphaned in Digital BSS. Tax line items do not recalculate; they preserve the original amounts from the source system.

Digital BSS platforms frequently use custom fields for operator-specific data such as loyalty points, VAS subscription flags, or region codes. We detect all custom field definitions, export their values per subscriber or account, and map them to equivalent Salesforce custom fields with appropriate data types (Number for loyalty points, Checkbox for VAS flags, Picklist for region codes). Custom field metadata (API name, data type, picklist values) is captured in a Field Inventory document for the customer's Salesforce admin to create before data import begins.

Mapping between BSS records and physical or virtual network elements (e.g., MSC, GGSN, PGW identifiers, cell tower references) is platform-specific and not portable across BSS vendors. These records are scoped out of the migration entirely. We document the source network element identifiers in a Network Element Reference sheet for the operator's network team to cross-reference during PCRF and HSS reconfiguration in the destination environment.