Using Porter functionality, you can transfer some of your existing customers to the target system and immediately run services there with minimum reconfiguration efforts.
Porter is a script with which you export a customer’s service and billing configurations and all of the dependent entities (accounts, products, service features, xDRs, invoices, etc.) from a previous “source” system and import them into the target.
As a result, the following data is transferred:
|
Entity |
Transferred Data |
|---|---|
|
Customer |
Customers’ configuration:
Generic configuration:
|
|
Vendor |
|
By default, customer xDRs that pertain to the current billing period are transferred. However, you can reconfigure Porter to transfer all of a customer’s xDRs, if necessary.
TIP: To enable customers to use the services in the target system sooner, you can perform two-phase data transfer: first transfer customers without
their xDRs. Then, transfer these customers’ xDRs with the second run of Porter.
Reseller data is similarly transferred: the reseller configuration and that of their customers and subresellers is transferred.
To preserve bilateral traffic exchange for vendors, pre-configure them as customers on the target system.
For the administrator’s convenience, the following general configuration data can be separately transferred (either assigned or not to a customer or an account):
- Products;
- Subscriptions;
- Volume discount plans;
- Tariffs and rates;
- Customer classes;
- DID pricing batches and DID groups;
- Custom field names;
- Destinations;
- Destination groups and destination group sets;
- Nodes.
Porter operates in interactive mode. This means that if during a data transfer some entity appears to already exist in the production system (e.g., you transferred the product earlier), you may choose to use this entity or create a new one.
When transferred, a customer and their accounts acquire the 
Exported status in the source system. This means
that customer service provisioning and billing is stopped. As soon as the administrator imports the customer, it resumes in the target system.
To reduce this downtime, during which a customer is “in-between” systems and cannot use the services, Porter creates a lineup of entities to transfer and processes them one by one. In other words, it exports customer A’s data from the source system and immediately imports it to the target. Then it repeats that same procedure to transfer customer B, etc.
For the data transfer to take place, the following entities must be pre-configured in the target system:
- A PortaBilling root user;
- Users for your staff members;
- Currencies;
- Payment systems;
- Templates (invoice, tariff upload/download);
- Taxation methods;
- Off-peak periods.
These functionalities must also be pre-configured in the target system if a customer or an account uses them:
- Routing plans.
- Routing categories.
- Routing criteria.
- Service policies.
- Internet access policies.
- Geo-risk profiles.
- CPE profiles.
- Fraud traffic profiles.
- Voice applications.
Dual Version PortaSwitch provides a mechanism for automatic synchronization of call records between source and target systems. As a result, you can access and download the call records in the Dual Version PortaSwitch system regardless of the system (source or target) on which they were initially created.
Dual Version PortaSwitch maintains the service integrity for your customers through constant synchronization of their call records with the help of a script that runs on the target system on set intervals of time.
When a new call record appears in the source system, the file is synchronized with the target system with the help of the script, even if the corresponding customer wasn’t migrated to the target system yet. When the customer finally fully migrates to the target system, all call records will already be present there.
Porter can migrate several customers in parallel, which allows you to increase data migration performance.
To enable parallel processing for Porter, the number of threads for data migration must be defined in the Porter configuration. This maximum thread number depends on the server’s processing capacity and the load caused by other operations running on that same server. Contact PortaOne Support to evaluate the number of threads available for Porter in your installation.
Customers may face issues with the target system after the transfer. If these issues should require deep investigation, an administrator can restore the customer on the source system.
To do this, the administrator runs the Retrop tool on the target system where the script performs a reverse transfer of customer xDRs as follows:
- first it analyzes the customer xDRs on both systems to find which ones of them can be returned (i.e., for services and entities that exist in both systems),
- it marks the customer record as Exported in the target system,
- then it imports the xDRs to the source system, and finally,
- it lifts the Exported status from the customer record in the source system,
- adjusts the customer’s balance so that it corresponds to the customer’s balance on the target system. If the customer has debit accounts their balance is also adjusted.
If the customer has used the services on the target system and therefore has new xDRs, Retrop generates the report for the administrator. The administrator then uses that to adjust the customer balance manually.
Note that a reverse transfer of customer xDRs must be treated as an emergency measure due to the following limitations:
- The xDRs must be returned before the customer’s billing period closes to avoid double charging, taxing and invoicing.
- When restoring the customer record on the source system, the service configuration will be rolled back. This means that any configuration changes done on the target system (e.g., new service enabled) will be lost.
- If the administrator has terminated the customer in the source system, the Retrop tool will not be able to perform a reverse xDR transfer.
- If the administrator terminates a customer’s account in the target system but the account still exists in the source one, the account will remain active after the Retrop tool performs a reverse xDR transfer and lifts the Exported status from the customer in the source system.
If you migrated some customers to the target system for testing purposes and later wish to return them to the source system, you need to remove the exported customer data.
To do this, use the Cleaner tool. Cleaner is a script that collects customer data and all its dependent entities and then deletes their records from the database. You can run Cleaner from either system in Dual Version PortaSwitch, however, you must define beforehand where the data is to be removed from.
Thus, with Cleaner you can remove the following entities:
- Customers,
- Distributors,
- Products,
- Resellers,
- Tariffs,
- Vendors,
- Access levels,
- DID numbers,
- SIM cards, and
- CPE.
Similar to Porter, Cleaner allows you to delete entities one by one or several at a time. This ability to delete unnecessary data facilitates troubleshooting and optimizes the overall management of Dual Version PortaSwitch.
Cleaner is designed to remove only data that has been transferred. Therefore, do not use it for simple system cleaning.
