IOSOR Learn

Retire Legacy Product SKUs Without Disrupting Active Ledger Billing

Learn the systematic approach to deprecating legacy catalog SKUs in IOSOR while ensuring ledger continuity, audit integrity, and zero service interruption for active tenants.

Retire Legacy Product SKUs Without Disrupting Active Ledger Billing.

Establishing the Deprecation Lifecycle

Managing a white-label CPaaS catalog requires a strict lifecycle for product SKUs. When a legacy SKU reaches its end-of-life, you must transition it to a 'deprecated' state rather than deleting it. Deletion destroys the ledger history, which is catastrophic for billing audits. Instead, mark the SKU as 'hidden' in the console. This prevents new tenants from selecting the product while allowing existing tenants to continue their current billing cycle without disruption.

Managing Active Ledger Billing

Existing tenants tied to legacy SKUs must remain functional until they migrate. When a SKU is deprecated, the ledger continues to process MRC and usage-based charges based on the historical association. Do not force a migration mid-cycle. Instead, use the IOSOR API to flag these accounts for a transition period. Ensure that the USD 20 prepaid floor remains active for these accounts, as the ledger requires a positive balance to process ongoing DLR and SMS traffic.

Handling JIT Provisioning and Numbers

Since IOSOR utilizes JIT provisioning, legacy SKUs often point to specific number pools. When deprecating, you must ensure that the E.164 routing logic remains intact. If a legacy SKU is removed from the active catalog, the JIT engine must still recognize the association for existing numbers. Never unassign numbers from a deprecated SKU until the tenant has successfully moved to a new product tier, otherwise, you risk immediate service failure.

Audit Integrity and Compliance

Maintaining historical records is non-negotiable. Every deprecated SKU must retain its metadata, including original pricing and tax configurations. This data is vital for financial reporting. If a tenant requests an export of their usage history, the system must be able to map the deprecated SKU back to a valid ledger entry. This ensures that your audit logs remain transparent and compliant with internal financial standards.

Operational Best Practices

To manage the transition, monitor accounts approaching the USD 1,000/month threshold. These high-volume tenants often require a soft review before moving them to newer SKUs. Use the following resources to manage your catalog operations effectively:

Start with IOSOR

Open the IOSOR admin console and update the legacy catalog entry to the 'deprecated' state instead of deleting the database record. Configure your catalog webhook listeners to reject new provisioning requests while allowing active billing loops and MRC deductions to continue undisturbed. Before toggling catalog visibility off, verify in the console that historical JIT routing rules and E.164 mappings remain attached to active sub-accounts.

IOSOR takeaway

Retiring legacy catalog entries requires separating active billing execution from new product selection without destroying financial history. Soft-flagging legacy SKUs preserves historical price locks, tax configurations, and routing context necessary for compliant audits and uninterrupted service delivery for existing tenants.

Do set legacy catalog entries to deprecated and allow automated billing to continue until an account reaches its planned migration window. Don't hard-delete SKUs from the catalog database or sever historical JIT provisioning associations, as doing so instantly breaks active tenant traffic and corrupts financial audit trails.

Was this guide helpful?

Related guides