Considerations and limitations in Dual Version PortaSwitch

• DNS configuration. For each domain specified on the Configuration server web interface in the VirtualHosts*.server_name and VirtualHosts*.server_alt_name fields, two additional prefixed domains must be manually created in DNS, one for the source system and one for the target system. A prefixed domain is formed by adding a system-specific prefix to the original domain name, e.g., source-billing.telecom.com and target-billing.telecom.com for an original domain of billing.telecom.com.DNS records must be created for all prefixed domains. Without them, browsers cannot resolve prefixed domain links, e.g., links to account self-care generated in the admin interface.If prefixed domains must be served with trusted certificates, request a dedicated certificate for each prefixed domain or use a wildcard certificate for the parent domain.
• Invoice number sequencing. For migrations where the source system runs MR99 or an earlier release, the source and target systems generate invoice numbers independently, which can produce duplicates across the two systems.For migrations where the source system runs MR100 or a later release, duplicate invoice numbers are prevented automatically: the source system generates odd numbers (1, 3, 5, …) and the target system generates even numbers (2, 4, 6, …).
• Shared outgoing IP address. The dispatching session border controller (DSBC) serves as the single outgoing IP address for both the source and target systems. Only one IP address needs to be allowlisted on the vendor or customer side, regardless of the system currently handling the traffic.
• Media streaming. The DSBC handles call signaling only and does not relay media streams. Once a call is established, media is exchanged directly between endpoints or via the RTP proxies of the respective PortaSIP clusters on the source and target systems. If vendors or customers restrict RTP traffic via firewalls, they must allowlist the PortaSIP server IP addresses from both the source and target systems.
• Additional DSBC servers for a second Dual Version jump. If you plan the next Dual Version migration, you need additional DSBC servers on the new target system. The number of required servers depends on the DSBC configuration from the previous jump:
  • If the first jump used one DSBC server on the target system, the second jump requires at least one DSBC server on both the source and the new target systems – two servers in total.
  • If the first jump used two DSBC servers on the target system (for redundancy), the second jump requires two servers on both systems – four servers in total.Plan for the additional hardware before starting the next Dual Version jump.
• xDR Mediator redeployment. xDR Mediator must be deployed on the target system before customer migration begins.
• Database size expansion. In a Dual Version migration where the source system is on a release prior to MR115 and the target system is on MR115 or a later release, the target database may consume up to twice the disk space of the source database. This is due to the MySQL upgrade (from 5.7 to 8.0).

• WebDispatcher redirection scope. The WebDispatcher automatically redirects customers and accounts to their self-care web interfaces based on which system their record is currently located on. Resellers are also automatically redirected to the reseller portal for Dual Version jumps from MR85 to MR100 and later.Administrators and representatives are always redirected to the web interface located on the target system. Administrators can use the URL of the source system to access the source system manually.
• Web passwords. Web passwords are not synchronized between the source and target systems during a Dual Version migration. This means passwords may expire on one system while remaining valid on the other, locking out administrators or other users mid-migration. To prevent this, check the Web.Password_expire value on the source system. If the expiration period is too short to cover the migration, extend it temporarily on both systems. Restore the original value once the migration is complete.
• Password encryption match. Both the source and target systems must have the same Security.EncryptPasswords value throughout the migration. A mismatch prevents one system from validating passwords created on the other system, causing authentication failures for users and administrators.

• PortaSIP API. The PortaSIP API is supported on the WebDispatcher side for source systems running MR92 or later.
• CallControl API. The CallControl API is supported on the WebDispatcher side for source systems running MR91 or later.Two additional constraints apply specifically for MR70-6 to MR85-6 migrations:
  • The source system does not support the CallControl.enable_api_notifications and CallControl.disable_api_notifications methods.
  • The Account/Customer.enable/disable_api_notifications methods are obsolete on the target system. If these methods are still required, enable the API.AllowObsoleteMethods option on the target system's Configuration server web interface. Consider changing the application to stop relying on these methods for the long-term.
• ESPF API. The ESPF API is not supported on the WebDispatcher side. Webhooks are sent directly from the source and target systems, bypassing the WebDispatcher entirely. External systems must be configured to receive events from both systems concurrently.When an external system receives an ESPF event and needs to retrieve additional details from PortaBilling, configure it to determine which system the relevant entity is currently on. To do this, the external system should call get_customer_info on the PortaBilling API and check the bill_status field in GetCustomerInfoResponse: a value of E indicates the entity has been migrated to the target system.

• Vendors. Vendor configurations on the target system are copied from the source system during the creation of the initial database snapshot.
  Vendor xDRs created on the source system after the snapshot are not automatically carried over to the target system, so the vendor balance may differ between the two systems during migration. Once all billing entities are migrated, the PortaOne team can synchronize vendor xDRs manually upon request.
• Distributors. Distributors cannot be migrated automatically and must be manually recreated on the target system. Their configuration must be kept in sync with the source system throughout the migration.
• Representatives. Representatives assigned to multiple customers or resellers must be migrated before the customers or resellers they are assigned to.
• Subresellers. Subresellers cannot be transferred separately from resellers. The entire reseller hierarchy must be migrated at once, starting from the top-level reseller.
• CC staff / Reseller individuals. CC staff entities managed by resellers are migrated together with their corresponding reseller.For migrations from a source system running on MR115 or an earlier release, to a target system running on MR120 or a later release, CC staff entities are automatically converted to reseller-managed individuals during the migration.

• Call recordings. Any call recordings made on the source system are automatically copied to the target system. Recordings made on the target system are not copied back to the source.
• Excluded logs and data. By default the following data is not migrated to the target system, but the PortaOne team can migrate it upon request:
  • SIP and billing logs
  • Web logs
  • cdr_mediator collections

The following data cannot be migrated:

• • .csv files with custom report results

• Zendesk. If you use Zendesk as a support ticketing system integrated with PortaBilling, the Zendesk event handler must be enabled on both the source and target systems. After a customer is migrated to the target system, ESPF events are generated on the target system automatically – no additional Dual Version configuration is required.Each billing environment requires a separate Zendesk domain. Reusing the source domain on the target system results in duplicate ESPF events being generated by both systems.Since the Zendesk hostname and credentials are stored in the browser's local storage for each user, there are no global defaults, and the admin cannot apply the hostname change to all users at once. Each staff member must obtain the current hostname and then configure their credentials.
• Request Tracker (RT) ticketing system. RT data migration is disabled by default. If ticket history must be preserved after migration, contact PortaOne Support.RT must be configured on both the source and target systems. If RT is configured only on the target system, requests for customers who have not yet been migrated are redirected to the source system. But since RT is not configured on the source system, those requests fail.

• Oracle installations. Dual Version migration is not supported if the source system uses an Oracle database.
• Product catalog freezing. During the Dual Version deployment and provisioning stage, modifying existing products on the source system is not allowed.
• Mail services. IMAP/SMTP requests are not automatically distributed across systems. After a customer/account is migrated to the target system, external mail clients must be reconfigured to send requests to the target system's URL.
• DID inventory. Neither the source nor the target system can act as a DID number provider for other PortaSwitch systems. DID exchange with wholesale partners is not available until the migration is complete.
• Secondary site functionality. WebDispatcher Dual Version features (authorization on both systems simultaneously and context switching) are not available on a secondary site. The secondary site operates in read-only mode and provides access to the target system only, without context switching support.
• WebDispatcher domain-only access. The WebDispatcher can only be accessed using domains. A proper domain name must be configured and used. Direct access via an IP address is not supported.

• SMS and SMPP delivery. The DSBC does not support incoming SMS dispatching.The SMPP proxy operates locally and does not distribute incoming SMPP requests across systems. External SMS providers must establish separate TCP connections with both source and target systems to deliver SMS.
• Callback services. Web and email callback services operate locally and do not dispatch requests across systems. After a customer is migrated to the target system, the callback service must be reconfigured with the target system's web page and email addresses. During the migration, both configurations must be maintained in parallel: one for customers still on the source system, and one for customers who have already migrated to the target system.
• DID number routing. The DSBC has no routing information about voice application entry points. All customers and accounts using a specific voice application must be migrated at the same time as the application itself.For the same reason, calls from vendors via a "From vendor" connection are not supported on either system if the DID number is defined directly on an account or voice application without being added to the DID inventory.