Migrate from Digital BSS to Mailchimp

Digital BSS Subscriber records map to Mailchimp contacts within a target Audience. The subscriber's email address becomes the contact email; first name and last name map to Mailchimp FNAME and LNAME merge fields. Subscriber status (active, suspended, churned) becomes a tag on the contact rather than a stored field because Mailchimp contacts do not have a native status field. We resolve the primary email address from the subscriber record and flag any subscriber with no email address as a skipped record for manual enrichment before cutover.

Digital BSS service plan names become Mailchimp tags on each contact. For example, a subscriber on the Premium-10GB plan gets tagged Premium-10GB, and a subscriber on the Basic-2GB plan gets tagged Basic-2GB. Mailchimp uses these tags as the basis for segmentation (plan-tier campaigns, upgrade promotions, data-exhaust notices). We extract the full plan name as the tag value and optionally prefix with a tier label (e.g., TIER_PREMIUM, TIER_BASIC) for easier segment filtering in Mailchimp's audience builder.

Digital BSS billing account fields map to Mailchimp merge fields on the contact. Billing cycle (monthly, prepaid, quarterly) maps to a BILLING_CYCLE merge field. Account balance (AR balance, credit limit) is not migrated to Mailchimp because financial balances do not belong in an email marketing platform, but the account creation date migrates as an ACCOUNT_CREATED merge field for recency-based segmentation. Payment method type (credit card, bank draft, carrier bill) maps to a PAYMENT_TYPE tag if segmentation by payment method is needed for marketing.

Any Digital BSS custom fields on the subscriber record that are marketing-relevant (e.g., preferred_contact_language, marketing_opt_in flag, device_type, home_region) migrate to Mailchimp merge fields of the appropriate type (text, number, date, or dropdown). Fields that contain technical identifiers (OCS bucket IDs, PCRF rule references, HSS IMSI numbers) are flagged as excluded because they are not relevant to email marketing and would introduce sensitive data into the Mailchimp audience.

Active subscriptions and plan change orders migrate as tags on the contact rather than as standalone records because Mailchimp does not have a native subscription order object. We tag subscribers with ORDER_ACTIVE, ORDER_PENDING_CANCEL, or ORDER_CHURNED based on the most recent subscription status in Digital BSS. This enables Mailchimp segments for win-back campaigns (ORDER_CHURNED) and upsell campaigns (ORDER_PENDING_CANCEL). The order history is not migrated as a linked record set; we deliver a written order history summary per contact as a reference document for the marketing team.

Digital BSS product catalog entries (tariff plans, bundle definitions, cross-service discounts, allowance formulas) do not map to any Mailchimp object. We extract the full catalog tree and deliver it as a written inventory document that the marketing team uses to design Mailchimp segments and automation triggers. For example, a bundle definition showing a data rollover feature becomes a marketing angle in a campaign rather than a data field in Mailchimp.

OCS prepaid balance buckets carry live monetary value and belong in a charging system, not an email marketing platform. Migrating bucket balances to Mailchimp would expose sensitive financial data and serve no marketing purpose. We do not migrate OCS bucket records. We flag the last-billed usage date per subscriber so the marketing team knows which contacts are likely to churn due to balance exhaustion, and we note this as a segmentation signal rather than a data field.

PCRF policy rules govern QoS, data caps, and network policy enforcement per subscriber. These are network-level configurations with vendor-specific syntax that cannot be represented in Mailchimp. We do not migrate PCRF rules. We note which subscribers have PCRF records as a binary indicator in our migration manifest so the network team can reference the rule set when provisioning new BSS platforms, but this data does not appear in the Mailchimp audience.

Authentication, Authorization, and Accounting records plus Home Subscriber Server data manage device-level and subscriber-level network access. These records contain IMSIs, credentials, and device identifiers that are sensitive and irrelevant to email marketing. We do not migrate AAA or HSS records. The migration manifest includes a count of affected subscribers for the network team's reference only.

Call Detail Records and usage events are archived records in Digital BSS and do not map to any Mailchimp object. Migrating historical usage data to Mailchimp would degrade deliverability by inflating audience size with inactive contacts. We extract the last-billed usage date per subscriber as a signal for segmentation (contacts with no usage in 90+ days become a suppression candidate) and deliver this as a reference dataset, not as contacts in Mailchimp.