Migration steps and timeline

Dual Version migration includes the following stages:

1. Pre-migration analysis
2. Dual Version setup
   1. Target system preparation
   2. Dual Version deployment and provisioning
3. Transfer of customers to the new version
4. Source system decommission

The duration of each stage depends on your system size and complexity (what services you provide and how, the number of active customers/accounts you have, and so on).

Sample customer

To consider an indicative migration timeline, let’s use the example of Panda Telecom, that:

• Provides SIP trunking services
• Has 2 “virtual environments”, used by two independent branches of the company in the US and UK (with their own set of products, customers)
• Has about 1,200 customers (3,000 accounts) across both environments. The number of CDRs in the system reaches 230M CDRs.

Panda Telecom plans Dual Version migration to update their system from MR85 to MR100.

Let’s consider each stage in more detail. We will also see how much time these stages take for Panda Telecom.

The pre-migration analysis (PMA) stage ensures the smoothness of the Dual Version migration and is mandatory for any migration with Dual Version (first or subsequent).

During this stage, we collect information to gain a clear understanding of your system peculiarities and plan how to deal with them in the scope of the Dual Version PortaSwitch solution. PMA is performed by the PortaOne team involving your engineers.

Example 1

One of the biggest concerns is “integration points” which are the external components your system is connected to, as you may have various integrations – with DID providers, external CRM systems, third-party or in-house developed self-care portals, and so on.

During the Dual Version setup, we will need to switch the requests from external components to DSBC (dispatching session border controller), which automatically dispatches the requests between the source and the target system.

To ensure that these integrations work on the target system as expected, we need to make a list of external components your system is connected to and consider all the peculiarities (whether any changes are needed on the external system side).

Say, if an external portal performs direct queries to the PortaBilling database, they will need to be replaced with API requests, which then will be automatically dispatched between the source and the target system by DSBC. As a result, the portal will continue to work smoothly during the migration.

Example 2

During the PMA, we may find out that some custom code modifications were made on your system (e.g., MR85) a few years earlier. In this case, we can decide together whether this modification is needed on the newer release (e.g., MR100) and what actions are required from both teams (e.g., prepare and verify the new code modification that is applicable on MR100).

Summary

PMA results allow us to create a tentative migration plan and make sure we don’t miss any important things. We can address any inconsistencies/incompatibilities and take preventive steps before we start the migration so that delays and issues in the later stages are avoided to the maximum extent possible.

PMA for Dual Version vs traditional update

A similar pre-migration analysis is also relevant for traditional updates (with a maximum of five releases per “jump”). For example, in the case of a traditional update, at least three rounds of pre-update analysis are required to get from MR85 to MR100 (MR85>90, MR90>95, MR95>100). Unlike the traditional update, with Dual Version you need a single PMA for one “jump”, as you can cover a large gap in software versions at once.

Main points that we analyze during the PMA:

• Your current (source) system details, such as:
  • Hardware
  • Network architecture
  • Number of environments and billing entities, for example, customers, accounts, and resellers
  • Provided services and functionalities
  • Auxiliary services, e.g., CDR import
  • Custom settings
• The current integration points (the external components your system is connected to) such as:
  • Third-party systems integrated with PortaBilling, e.g., CRM systems
  • Custom web portals and any other external applications using PortaSwitch API (we also check whether there are any applications that use direct database access)
• Custom code modifications on your system
• Custom reports and SQL scripts
• The target system requirements, e.g., the hardware needed for the target system (choosing physical vs cloud), network configuration.

Based on the PMA, you receive an analysis that includes:

• A high-level diagram of the “integration points” (network components) involved.
• The list of code customizations that should be replicated on the new release system (adjusted to the new release version and verified).
• A tentative migration plan with the steps and responsibilities (we agree on what should be done in the next stages on both sides, e.g., if your reseller has its own self-care portal, we agree on who will be responsible for testing it).
• A migration matrix (customer segmentation by batches – we agree on what batches should be migrated first).

In the PMA stage, we also discuss and decide on the date when you will need to temporarily stop making changes in the product catalog.

When the Dual Version deployment and provisioning stage starts, a temporary product catalog freeze will be required, which means that it won’t be allowed to change the configuration and pricing of the existing products until the migration is completed.

Say, if you plan to change the monthly price for your EasyCall product from 10 USD to 12 USD, you have a “last chance” to make these changes on the source system before we proceed with the “Dual Version deployment and provisioning” stage.

On the other hand, you can introduce new products and launch new services on the target system immediately after the “Dual Version deployment and provisioning” stage is completed.

A list of all restrictions for a specific entity on the source or target systems during migration will be added soon.

The PMA stage requires at least two weeks (10 business days). The actual timeline depends on your system size, the provided services and features diversity, the number of customizations and integrations, etc. For the most complex setups, the PMA stage may take up to four weeks (20 business days).

For the service provider Panda Telecom from our example, the PMA took 7 business days.

This stage includes the target system preparation, configuring two systems (source and target) operating in parallel, and all other steps that should be done before customer migration.

If the target system is deployed on-premises, your team performs the following steps:

1. Hardware preparation (including servers for DSBCs)
2. Software installation from the .iso image
3. The configuration of DSBC that will process SIP, RADIUS, Diameter, API requests, setting up the network on the target system, and network connectivity between the source and the target systems

Note that in case the target system is deployed in the cloud, steps 1-3 are performed by the PortaOne team.

In any case, the PortaOne team performs post-install and performance testing on the target system.

Once the target system is ready, the PortaOne team proceeds with the Dual Version deployment and provisioning (making two systems – source and target – operate in parallel).

The PortaOne team reconfigures the database in such a way that any new entities (e.g. customers or accounts) created on either system will have unique IDs across the two systems. This allows to combine these entities in a single database later on, when the migration is completed.

After the source system database has been reconfigured, it is copied to the target system.

From this moment on, any changes in the product configuration on the source system are not allowed as it may break data consistency between source and target and lead to migration issues. For the source system version starting from MR100, such changes will automatically be blocked, both via the web interface and via the API.

All the requests, such as VoIP call initiation or API requests from an external CRM, still go directly to your source system, so now we need to switch these requests to the DSBC. It dispatches the requests between the source and target system automatically, depending on where the corresponding user record is located at the time (from the users’ point of view, nothing changes). For this, we perform the IP address switchover, which means that the DSBC takes over IP addresses that used to belong to the source system, so requests from your customers, vendors or applications arrive to the DSBC.

IP address switchover is performed separately for:

• Voice calls – approximately 3-minute downtime per PortaSIP cluster is expected.
• RADIUS/Diameter requests (this step is needed if there are external gateways, or you import xDRs from external systems) – approximately 5-minute downtime is expected.
• API requests – approximately 5-minute downtime is expected.

For Panda Telecom, the “Dual version deployment and provisioning” process took approximately 4 man-days of engineering time, but it was performed over 13 business days, allotting time for task and time slot coordination with Panda Telecom’s engineers.

The process of transferring customers to the target system (customer migration) is described in the How it works chapter. The customers can be migrated in selected groups (customer batches). Each customer may experience a short service disruption (one min or less for an average customer with up to 100 accounts).

The PortaOne team checks logs for errors/warnings to make sure the migration process went as expected. And your team tests the scenarios for the migrated customers and collects feedback on the user experience. If any issues occur, it’s possible to transfer back only the affected customer to the source system. The customer can use their services as usual, so the engineering team has as much time as they need to troubleshoot the issues.

Then you can proceed with the next customer batches.

When the source and the target system operate in parallel, the xDRs for vendors are produced on both systems (depending on where the customer is located) and are not synchronized automatically. So, the PortaOne team runs the xDRs synchronization manually after all the billing entities (customers, accounts, resellers, etc.) of a specific billing environment are migrated to the target system. After that, you can generate accurate reports, e.g., if you need to reconcile a vendor’s invoice, in the single place (target system) that already contains all the vendor billing data from both systems.

For Panda Telecom, the “Migration” stage was completed in 25 business days (5 weeks).

Panda Telecom had just ten similar products, so they divided customers into batches based on their size and amount of traffic used rather than on the product assigned. The largest customers were migrated within different batches so that Panda Telecom could test the services for these customers at a comfortable pace.

During the first week, the PortaOne team performed a test migration of the pilot batch of 20 customers. Once Panda Telecom confirmed that all the services worked as expected for these customers, the next 100 customer-batch was migrated over the next few days.

During the next four weeks, the migration continued at a similar pace: 100- or 150-customer batches were migrated once every few days during the off-peak hours.

When you see that everything works well on the target system (e.g., 2-4 weeks have passed or at least one billing period has been completed after the end of migration), the source system can be decommissioned (disconnected from the target system). In the future, it can be used as a target system during the next migration, so you can update your system the same way again.

Your current target system will be switched to the “normal” mode (so it will function as an independent system).

For Panda Telecom, it took 1 day to plan and prepare the source system decommission, and then a new configuration was applied within a chosen off-peak period.