Migrate from Digital BSS to Twenty CRM

Digital BSS Subscriber records (IMSI, MSISDN, subscriber status, plan assignment, HSS credentials) map to Twenty CRM Person records. We extract the subscriber identifier, service type, plan reference, and status as standard Person fields. HSS authentication credentials do not migrate to Twenty's user-facing CRM; they remain in the network layer and are documented in the network handoff manifest. Subscriber type (prepaid/postpaid) becomes a custom picklist field on Person.

Digital BSS Billing Accounts (linking subscriber to payment method, invoicing preferences, AR records, credit limits) map to Twenty CRM Company records. We preserve the billing account ID as a custom external ID field, account balance as a currency field, credit limit as a custom field, and invoicing preference as a text field. Tax configuration does not migrate and must be rebuilt in Twenty's settings. Open AR balances transfer as a reconciliation step before cutover.

Digital BSS Service Plans include rating rules, chargeable events, and bundle allowances. We create a custom ServicePlan object in Twenty to capture plan name, plan code, rating type (prepaid/postpaid), included allowances (voice minutes, data volume, SMS count), overage rates, and bundle constraints. Plan-to-subscriber assignments link via a lookup field from Person to ServicePlan. Where plans map to sellable offerings, we also create Twenty Products for downstream quoting and Opportunity line-item use.

Prepaid OCS balance buckets carry live monetary value. We create a custom OCSBucket object in Twenty with fields for bucket ID, subscriber reference, bucket type (airtime, data credit, SMS credit), current balance, currency, last recharge timestamp, and expiry date. We perform a two-phase cutover: first write all bucket records to a shadow staging area in Twenty, then after verification trigger the destination OCS to serve those buckets, with a brief read-only window on the source to prevent double-spending. This is the highest-severity migration step because subscriber credit loss is irreversible.

Digital BSS Order records (plan activations, plan changes, service cancellations) map to Twenty CRM Opportunity records. Each order becomes an Opportunity with the subscriber's Person record and the plan's ServicePlan custom object as lookups. Order status maps to Opportunity stage (Qualification for pending, Negotiation for in-progress, Closed Won for activated, Closed Lost for cancelled). Historical timestamps preserve on Opportunity creation date and last modified date.

The Digital BSS Product Catalog defines offerable services with relationships to plans, pricing, and bundle constraints. We extract the full catalog tree and map it to Twenty Products for commercially offerable items and to a custom ServiceCatalog object capturing the full bundle hierarchy including constraints, cross-service discounts, and allowance formulas. The catalog mapping specification is reviewed by the operator's product manager before catalog activation.

Call Detail Records and usage events from Digital BSS are typically archived rather than migrated live. We extract the last-billed usage timestamp and flag any usage records between the last bill date and cutover date as unrated. These are documented as a gap in rating that the destination OCS must handle on first subscriber recharge. Historical usage records that the operator wishes to preserve migrate as custom UsageRecord objects with call type, duration, volume, destination, and timestamp.

Digital BSS platforms frequently use custom fields for operator-specific subscriber and account data. We detect all custom field definitions in the source platform, export their values per subscriber or account, and create equivalent custom fields in Twenty. Custom field types are mapped to Twenty field types (text, number, date, picklist, currency) during the schema design phase. Any custom field without a Twenty equivalent is added as a text field with a note in the migration manifest.

Historical invoices from Digital BSS can be exported as PDFs or structured records. We map invoice line items to a structured data format stored against the relevant Company record, and export invoice PDFs as attachments. Open AR balances that must transfer before cutover are reconciled as a separate step and noted on the Company record. Invoicing configuration (tax rates, billing cycle, payment terms) must be rebuilt in Twenty's settings post-migration.

PCRF policy rules, HSS subscriber records, and AAA data use vendor-specific syntax that does not port cleanly between BSS platforms or into a general-purpose CRM. These records govern QoS, data caps, policy enforcement, and device-level network access. We do not migrate them. We extract the raw rule definitions and produce a translation manifest that the operator's network team reviews and rebuilds in the destination network environment. This is documented explicitly in the network handoff section of the migration manifest.