Migrate from Digital BSS to Nutshell

Digital BSS Subscriber records carry IMSI, MSISDN, service type, plan assignment, status, and balance properties. We map subscriber name and contact details to Nutshell Contact fields. The original subscriber plan assignment is preserved in a custom field for the sales team to reference. Active and suspended statuses map to Contact status flags. Subscriber records with no contactable person (machine-to-machine IoT SIMs) are not migrated because Nutshell has no device-record object equivalent.

Digital BSS Billing Accounts link subscribers to payment methods, invoicing preferences, and AR records. We map the billing account name to Nutshell Account and payment contact details to the Account's primary contact fields. AR balance and credit limit transfer to custom fields on the Account because Nutshell does not have a native AR object. Tax configuration does not migrate and must be rebuilt in Nutshell settings.

Digital BSS Service Plans define rating rules, chargeable events, and bundle allowances. We assess whether the plan should become a Nutshell Deal (for active commercial agreements) or a custom object (for plan catalog reference). Plan-to-plan mapping is not automatic because bundle codes, allowance formulas, and cross-service discounts are vendor-specific. We generate a plan mapping specification that the customer's product manager reviews before activation.

The Digital BSS product catalog defines which services are offerable with relationships to plans, pricing, and bundle constraints. We extract the catalog tree and map it to Nutshell custom fields or a linked custom object. The customer decides whether the catalog is a reference dataset (custom object) or is rebuilt entirely in Nutshell's product management area during the onboarding phase.

Order records for plan activations, changes, and cancellations map to Nutshell Deals with custom fields for order type, plan name, and effective date. Order history and status timestamps migrate. Closed orders preserve their status. Active orders that represent ongoing subscriptions migrate as open Deals with the plan name as the Deal name.

Call Detail Records and usage events are typically archived rather than migrated as live records. We flag the last-billed usage date on the subscriber record as a custom field to ensure no gap in rating when the new system goes live. If the customer requires usage history visible in Nutshell for account management purposes, we attach a structured Note summarizing high-level usage totals per service type.

Historical invoices can be exported as PDFs or structured records from Digital BSS. We map invoice line items to a structured Note attached to the Account or Deal and preserve the open AR balance on the Account as a custom field. Invoice PDFs attach as files to the Account. Closed invoices with zero balance are migrated as historical records only.

Digital BSS frequently uses custom fields for operator-specific data on subscriber, account, and order records. We detect all custom field definitions, export their values per record, and create equivalent custom fields in Nutshell before migration. Field type mapping from Digital BSS types (numeric balances, date fields, text codes) to Nutshell custom field types is performed during schema design.

Prepaid balance buckets carry live monetary value and require careful handling. We do not migrate OCS buckets as a record type into Nutshell because Nutshell has no charging or balance-tracking capability. Instead, we record the bucket balance as a custom field on the Account for the sales team's reference, and we provide a balance verification manifest for the customer's billing team to reconcile against the destination OCS separately. The OCS cutover itself is a network operations task outside the CRM migration scope.

PCRF policy rules govern QoS, data caps, and policy enforcement in the Digital BSS network layer. These have no Nutshell equivalent and are not migrated. We export the raw rule definitions and present them as a translation manifest for the operator's network team to configure in the destination network policy system. This manifest is delivered as a written document, not as an automated data load.