Seamless web UI operations for admins, customers, and other entities

Dual Version PortaSwitch includes a mechanism called “WebDispatcher”. It enables web applications such as PortaBilling admin UI and self-care portals (e.g., the built-in customer self-care UI, the CloudPBX Self-Care Portal, or an external portal developed by the service provider on their own) to operate seamlessly with both systems – source and target – in parallel.

Users can continue logging in via their “old” familiar URL and maintain their usual routines, while the WebDispatcher retrieves the data either from the target or source system. This setup ensures a smooth user experience, as users don’t need separate URLs to access each system’s web UI. For example, a customer, John Doe will be able to log in to his self-care portal using the familiar URL www.customer.billing.com to check his balance and invoices, regardless of whether his customer record is still on the source system or has already been moved to the target system.

Let’s explore how users of different roles such as admins, customers, or resellers, interact with their web UIs in Dual Version PortaSwitch.

When admins open their “old” familiar URL, like www.admin.billing.com in Dual Version PortaSwitch, they are directed to the web UI of the target system, so they see the new version of the web UI.

During a Dual Version migration, admins manage both the customers who have already been migrated to the target system (e.g., MR115) and those still on the source system (e.g., MR100). For the admin’s convenience, a complete set of customers is accessible via the target system’s web UI.

For example, say an admin needs to check the subscriptions assigned to a specific customer. They log in to the target system via their familiar URL www.admin.billing.com. In the “Customers” screen, they search by customer name or other attributes. The result includes all customer records: those that have already been moved to the target system, those created on it, and those still on the source system. If a customer record is marked as read-only, it indicates that it is currently on the source system. To access and manage such a customer record, the admin simply clicks “Open in the source system,” which opens the web UI of the source system (older version). Alternatively, they can directly access the source system using its specific URL of the source system, such as www.100-admin.billing.com.

Admins can view the product catalog upon accessing the target system. Switching to the source system is not required, as the product catalog is copied to the target system before the migration starts.

For example, if the admin has bookmarked a link to a specific product (e.g., www.admin.billing.com/ui/product/23575) and then opens that link while the Dual Version migration is underway, they will be directed to the product page on the target system’s web UI after successful logging.

Сustomers and accounts can only interact with the system (either source or target) where their record is currently located. When they log in to the customer/account portal (the built-in self-care UI, a portal available via the Add-on Mart, or a portal developed by the service provider) using their “old” familiar URL, the data from the corresponding system will be provided by the WebDispatcher.

For more details, refer to:

• How it works for the built-in self-care interfaces provided with PortaSwitch
• How it works for external portals

When resellers, CC staff, or representatives log in to their self-care portals, the data from the system where their record is currently located (either source or target) is used.

The reseller’s records are always migrated along with the records of the associated entities, including their customers, sub-resellers, representatives, and CC staff. This practice ensures that the reseller’s customers and other entities are always on the same system as a reseller, so the reseller doesn’t need to switch between two systems (like admin). Consequently, the service provider doesn’t need to provide any additional instructions to the reseller, as they will continue using the same URL to manage all their customers. However, during the migration of a reseller, both the reseller and their entities (such as customers) cannot access their portals until all their records have been successfully migrated to the target system.

When a distributor logs in to their self-care portal, the data from the target system is used.