Overview

Dual Version PortaSwitch is a solution that allows you to update your PortaSwitch with minimal inconvenience and service disruption for end users and reduced engineering effort compared to traditional updates. Plus, you can start leveraging new features and launch new products using the latest release even while the update is still in progress.

With Dual Version, you can “jump” over multiple maintenance releases. The update is performed gradually by migrating groups of customers one by one to the newer release.

First, let’s consider the limitations of a traditional update that Dual Version is designed to solve:

• With a traditional update, you can only “jump” to the nearest long-term supported (LTS) release, which is any PortaSwitch MR ending with 0 or 5. For example, if you want to update your PortaSwitch from MR85 to MR100, you need to update first to MR90, then to MR95, and only then to MR100.
• For each such update to an LTS release, you need to perform a fair amount of testing/preparation to make sure that the equipment used by your customers (such as phones, mobile apps, and office PBX systems) and partners (gateways, proxies, and so on) all works perfectly with the new version and that all service scenarios function exactly as your customers expect.
• If something goes wrong, it will affect all customers (for example, if a specific model of IP phone does not work with the new release, it will affect every customer using this IP phone model). And if you choose to perform a rollback to fix the issue (meaning, return your system to the earlier version), that will lead to system-wide downtime and a negative experience for those customers who had already begun to use the functionalities that came with the newer release, and now will suddenly lose those functionalities.

All the limitations mentioned above are relevant for zero-downtime update as well.

Dual Version PortaSwitch allows you to avoid all of these challenges. Here’s how:

• It lets you quickly cover large gaps in software versions – for example, you can update your system from MR85 to MR100 in one “jump” to unlock the specific feature or features you need.
• Instead of planning for the multiple testing and preparation rounds required by a series of several jumps (for example, MR90 to MR95 to MR100), you only need to plan one round for one jump – resulting in a much lower investment of time and resources.
• You can transfer customers to the new release system in selected groups (customer batches), test new scenarios for them / collect feedback, and only after that continue to migrate the rest of your customers at your own speed. If something goes wrong, it will affect only a particular batch of customers, and you can easily transfer them back to the old version.

Dual Version migration is performed using a two-system setup in which the current release system, called the “source system” (e.g., MR85), and the newer release system, called the “target system” (e.g., MR100), operate in parallel. For example, you can migrate 20 customers to the target system, then wait a week to make sure that everything works properly and those customers are happy. Once you are satisfied that everything is running smoothly, you can transfer the next batch of customers.

While a customer batch is being migrated from the source system to the target system, each customer may experience a short service disruption (from several seconds to several minutes, depending on the number of customer’s accounts). Each customer in the batch will be able to start using their services on the new release platform (e.g., MR100) immediately after a short individual disruption while being transferred.

If any issues occur after these customers start using the newer release, you can transfer that customer batch (or only specific customers) back to the source system.

Here is how it might look if you encountered an issue after migrating a single customer batch from MR85 (the source system) to MR100 (the target system):

1. First, the customer batch (in this case, 20 customers) is migrated from MR85 to MR100.
2. In a few days, customer A reports that they are encountering several issues. You do not hear of any issues from any of the other customers in the batch.
3. You transfer back only the affected customer to the older system. The customer can use their services as usual, so the engineering team has as much time as they need to troubleshoot the issues.
4. The issues are fixed.
5. You migrate customer A to the target system again.

This is how Dual Version makes it possible to find and fix unforeseen issues before they affect all customers and ensure uninterrupted services for most of the customers. Also, you can test new features with minimal risk by delivering them to a small batch of customers instead of performing one “big bang” update.

Dual Version has two major components:

• Porter – This is a utility that transfers the data of customers (with their accounts), such as balance, configuration settings, xDRs, etc., from the source to the target system. Porter also transfers the data of resellers, representatives, and customer care staff. After the data transfer, these entities become active on the target system and consequently inactive on the source system. If some customers have issues with their services, you can choose to transfer back all of the customers from the batch or only the specific customers back to the source system.

  

• DSBC (dispatching session border controller) – This component sits “between” the two versions of the system to accept requests (e.g., VoIP call initiation or API request from external CRM) from users and deliver those requests to the system where the user record is located at the time – whether that is the source or the target system. This allows you to perform the migration without the customers/resellers needing to change any settings on their side.

  

• To perform a migration with Dual Version PortaSwitch, you need: Additional licenses for the target system (i.e., an extra system). Contact our sales team to get information.
• Additional hardware. The target system must contain the same number of servers as the source system, plus two servers for the DSBC. A cloud option is also available.

1. Jumps that have been tested at this moment are MR70 to MR85 and MR85 to MR100.
2. There is no need to test all “long tail” scenarios that could potentially be used by customers on the newer release (e.g., if, on the source system, a specific customer has a complicated follow-me configuration to dispatch calls between call centers). Instead, you can test the main scenarios only. If a specific customer from a migrated batch reports an issue, you can transfer this customer back to the source system and fix the issue.
3. Specific customers/batches can be transferred back to the source system.
4. A list of all actions that could be restricted for a specific entity on the source or target systems during a migration will be added soon.

• If issues arise with the new version, they will affect only a small group of customers (customer batch). After transferring those customers back to the older release, your team can deal with the issues in a non-urgent manner.
• Because there is no need for intermediate migrations, much less time is required from your engineering team for update preparation and testing of main scenarios.
• You can launch new products on the target system immediately after it is deployed.

• During migration, some operations are restricted for the administrator, for example, changes in the configuration of existing products.
• Non-zero (still short) downtime per customer.
• Additional hardware is required. See Requirements, above.