Dual Version PortaSwitch enhancements

Dual Version PortaSwitch is a solution for gradual migration to a newer PortaSwitch version across multiple releases. With Dual Version PortaSwitch, the migration is performed using a two-system setup where the current release system (called “source” – e.g., MR70) and the newer release system (called “target” – e.g., MR85) operate in parallel. A service provider can gradually transfer customers to the newer release system by arbitrarily chosen groups (customer batches).

Here are the main Dual Version enhancements.

The migration of entities includes copying the database from the source to the target system, then transferring batches of customer records using Porter. After the database is copied, you can safely change data only for customers, accounts, resellers, and representatives (Porter will transfer all the changes). The other entities such as products, subscriptions, tariffs, etc., become “frozen” and can’t be created/changed until the migration is finished. See what actions are possible for a specific entity on the source and target systems during the migration.

For jumps starting from MR100, the administrator won’t be able to make any changes for such “frozen” entities by default, neither via the web interface nor via the API. For jumps from MR70–MR99, changes are possible. See the entity management restriction for different Dual Version jumps.

Let’s say the administrator changes a “frozen” entity on the source system, for example, adds a new messaging service for a product while jumping from MR70. Porter will transfer the customer and their accounts to the target system, but messaging service will become unavailable. As a result, engineers will have to find and fix the issue: either rollback the affected customers or update the product on the target system (add messaging service). It takes time and slows down the whole migration process.

If the administrator creates a new product on the source system and assigns it to the customer’s account, this customer won’t be transferred to the target system.

The migration may take several months and you won’t be able to launch new services (create new products, etc.) If it sounds too long for your business, it’s recommended that you create new products, subscriptions, etc., on the source system before database copying. This ensures that you can start/continue providing services while the migration is underway.

• Ensure smoother migration by avoiding issues during customer transfer.
• Speed up the overall migration process.

This table shows which actions are possible for a specific entity on the source and target systems while the migration is in progress.

 – changes are allowed

 – changes are forbidden

Entity	Action	Changes on source system	Changes on target system
Customers Accounts Resellers Representatives Customer care staff	No automatic synchronization, transfer via Porter
	Change
	Add new and change it
	Terminate
Vendors	No automatic synchronization
	Change
	Add new and change it
	Terminate
	Note that vendors remain active both on the source and target systems.
DID/MSISDN inventory Pricing batches	Changes are synchronized automatically between source and target systems
	Change
	Add new and change it
	Delete
Destinations Rates (for tariffs created on the source system before the target system deployment) Call recordings	Changes are synchronized automatically from source to target system
	Change
	Add new and change it
	Delete
Service policies CPE CPE profiles Fraud traffic profiles Dialing rules	No automatic synchronization
	Change	*	*
	Add new and change it
	Delete
	* Make sure you made the same changes on the other system
Products Volume discount plans Tariffs (except rates) Subscriptions Roles Commission plans Custom data Customer classes Destination group sets Destination groups Routing plans Services Spending plans Templates Connections Nodes Reseller configuration (entities managed by reseller, e.g., product, tariff)	No automatic synchronization
	Change
	Add new and change it
	Delete
	If any of these entities created on the target system is assigned to customer/account/reseller/representative, rollback won’t be possible.
Distributors	No automatic synchronization
	Change
	Add new and change it
	Delete
Billing enviroments	No automatic synchronization
	Change (“Name” or “Description” fields)	*	*
	Add new and change it
	Delete		Newly created – Existing on source system –
	* Make sure you made the same changes on the other system.

• For jumps MR70–MR85 – there are no restrictions on the web interface and via the API. Make sure your administrator doesn’t make any changes for entities where actions are forbidden on the source/target system during the whole migration process.
• For jumps MR85–MR100 – there are no restrictions by default but they can be activated manually.
• For jumps from MR100 – the administrator won’t be able to manage the entities where actions are forbidden by default.

With this release, a customer who is currently in the process of migration from the source to the target system is explicitly indicated with a new Export in progress (billing paused) status.

It means that billing processes for this customer are paused: PortaBilling can’t close the billing period, calculate taxes, and generate invoices. Subscription charges won’t apply. The administrator can’t void, recalculate and re-issue invoices. However, they can change the customer information such as contact details, credit limit, payment method, etc. The customer can use their services and access the self-care interface (as it was on the source system before the migration).

Once the migration is finished, the Export in progress (billing paused) status is automatically changed to the customer’s pre-migration status, e.g., Active or Suspended.

The administrator can see on the web interface which customers are still in the process of migration.

Dual Version PortaSwitch now supports the transfer of permanently terminated customers from the source to the target system.

Customers may be terminated on the source system either before the migration process starts (before the source system database is copied to the target system) or during the migration process while they are pending transfer. Previously, only the customers terminated before the database was copied were displayed on the target system with the “Closed” status. Now, the customers terminated after the database is copied are also transferred to the target system. Such customers first receive the “Exported” status and after they are transferred – the “Closed” status.

The administrator can see all terminated customers on the target system.

Dual Version PortaSwitch now supports the migration of data from Request Tracker (RT), a trouble ticketing system. When the migration process starts, the RT database is copied from the source to the target system. If some changes are made in a ticket (e.g., a new comment is added) on the source system during the migration process, the changes are also transferred to the target system.

The RT data transfer is enabled by default. To speed up customer transfer, the administrator can disable the RT data transfer on the Configuration server by selecting the Porter.TransferAuxiliaryEntities option to No.

The administrator has access to RT tickets with up-to-date data.

At the beginning of the migration process, the auxiliary data used for history/statistics, such as Internet service usage details (“NetaccessUsageDetail”, “NetaccessUsageStat”), Audit log (“Log”, “WebLog”), and RT-related data (“CustomerRtUser”), is copied from the source to the target system. By default, if there are changes in this data on the source system during the migration process, these changes are also transferred to the target system after customer records.

To speed up the customer migration, the administrator can now disable transferring of the auxiliary data (“NetaccessUsageDetail”, “NetaccessUsageStat”, “Log”, “WebLog”, and “CustomerRtUser”) by setting a single option Porter.TransferAuxiliaryEntities to No on the Configuration server.

Service providers can reduce the overall migration time.