During migration

It will not be possible to change the configuration and pricing of the existing products until the last customer is migrated from the source (current) to the target (new) system. This is called a "temporary product catalog freeze” and is required once the Dual Version deployment and provisioning stage starts. However, you can introduce new products and launch new services on the target system as soon as the Dual Version deployment and provisioning stage is completed and the IP switchover from the source to the target is performed.

This means that you can start selling new products for your new customers on the target system even before you migrate your first existing customer from the source system!

Yes, there will be some downtime:

• During the Dual Version deployment stage, while reconfiguring the MySQL database on the source system, there will be a downtime of about 1 minute.
• During the Dual Version provisioning stage, there will be a few minutes of downtime while we make the switchover of the IP address used by your IP phones or external applications.

Also, during the migration of a customer, that customer will not be able to access their service for just a few minutes, depending on the number of accounts they have. At the same time, the rest of your customers will use the service as usual.

Dual Version has been designed to ensure smooth and controlled customer migration, which means that your customers can maintain their familiar routines. A customer can log into the same portal under the same address, regardless of whether their customer record is on your source or on the target system.

For example, customer John Doe will be able to log in to www.mybilling.com to check their balance and invoices, both when their customer record is on the source system, and after it is moved to the target system.

Let’s assume that all your 20,000 customers are using roughly the same product. For this, PortaOne usually suggests an approach with an initial period of about two to four weeks for testing your pilot batch of customers. The actual duration of the testing period will highly depend on the size of your system, the number of products, and any integrations or customizations that have to be verified. These factors drastically influence the duration of customer migration. We recommend categorizing customers, for example: in the first batch, we could migrate all customers who are using Product ABC; the 2nd batch for migration would contain customers who are using Payment System X, and so on.

For perspective, during migration, approximately 1,000 customers might be migrated from the source to the target system each night (during off-peak hours). Given this pace, it would take approximately a month to migrate your 20,000 customers with 200,000 accounts. You can find real-life figures from a few recent Dual Version migrations in this video presentation.

The number of customers in a batch is unlimited. What matters is how many data modification operations per second can your system (the database) handle without degrading the overall performance for real-time charging of calls that are in progress.

Migration of a single customer requires many update operations, for example, inserting a new customer record, inserting an account record under it, updating service settings, and so on. Since the Porter utility migrates a single customer at a time, we will run multiple Porter processes in parallel to shorten the overall time of the migration.

Since migration is usually performed during your off-peak period (in order to minimize the impact on your production services), the maximum size of the batch should be calculated or predicted based on the Porter performance in terms of the exact installation and size of the customers you are migrating (that includes the number of accounts, xDRs, and so on).

To minimize any risk of failure during a migration, we conduct a so-called "dry-run" with our Porter utility – in other words, a rehearsal.

Here is how it works:

• You provide us with the batch of customers that you want to migrate first.
• Our PortaOne team performs this migration in a “dry-run,” or rehearsal mode
• If any failures occur during this “dry-run,” we fix them promptly. Only then we schedule the real migration, with those failure risks already resolved
• When we’re ready to go, PortaOne will wait for another batch from your end, and we will repeat the same steps until all customers are migrated