Gradual migration with the help of Dual Version makes updates for clients with a large number of customers a more comfortable, nearly risk-free process in which test customer batches act as long-tail testers. We’ve collected information on recent and current technical approaches, our insights, and successful implementation use cases of Dual Version for our clients in a white paper, which is available for you to read now.
This new way for existing PortaOne clients to perform a gradual software update was first presented in a live webinar by Andriy Zhylenko (CEO) and Oleksandr Zaluhovskyi (Project Manager).
Watch the video recap below to learn how to:
- Reduce the number of UX issues that occur after an update
- Roll out updates to pilot customer batches, limiting possible issues to a small portion of users
- Drastically reduce the amount of time your engineering team spends on update preparation
- Perform release rollback only for the users affected by an issue
- Update over a large span of releases (e.g., MR55->MR70)
- Eliminate full service downtime during the update
- Launch new products even during active customer migration
- Minimize possible “oops” moments for reseller portals and other 3rd-party applications that cannot be fully tested beforehand
Webinar poll questions and results
During the webinar, we conducted a poll with the following results:
- 36% of responders are running PortaSwitch version MR70–MR79
- 27% are using MR55–MR69
- 23% are using MR80 or newer
- Only 5% are still using MR54 or older
The time necessary to prepare and execute an update varies. It takes:
- Up to 3 months for 38%
- 3–6 months for 19%
- 7–12 months for for 19%
- More than a year for 5%
(Percentages will not add to 100 as non-applicable respondents were excluded.)
More than a third of our respondents – 36% – have done a long jump update across 10+ releases without the possibility of rollback at least once. And an absolute majority of the webinar participants stated that they wish to shorten the time and effort required to prepare and execute an update – that’s “definitely yes” from 71%.
Webinar Q&As
Q: What is the difference between Zero downtime update (ZDU) and Dual Version PortaSwitch?
A: ZDU allows you to do a quick jump to the next release without an impact (downtime) for the customer base. But ZDU doesn’t address the potential UX issues that can arise if all customers start using a new release overnight and are not happy about it.
Q: Does the Dual Version architecture provide redundancy?
A: Dual Version does not involve redundancy as part of its design, but since it involves two systems running in parallel, it’s a good idea to make the source and target systems redundant (after a successful update). If a data center outage takes place for either source or target system during a long migration, it’s going to be visible. So Dual Version does not replace but instead works in conjunction with the current ZDU functionality available in PortaSwitch.
Q: Do I need to deploy DSBC if I already have a PortaSIP cluster?
A: Yes, you always need to have a DSBC. Even if you have a fairly new PortaSIP, it’s still a part of your source system, and is only aware of that specific system. So if you want to move from MR85 to MR90, you’ll need DSBC in front of your PortaSIP. It will decide whether to route calls to the PortaSIP cluster on the source system or on the target system.
Q: How long does it take to prepare and execute the whole update?
A: There are no specific time constraints from the perspective of architecture. It depends on the number of your products, lines of business, integration points, etc. And you’re free to decide how much time you’re going to allocate. The longer the update period, the more gradual the testing and the longer you can observe the pilot batch of customers to ensure they are completely happy.
The rule of thumb is 3-6 months for a small number of products and customers, but pre-migration analysis will provide a more precise estimate. We recommend spending at least one month (full billing period) on testing the first pilot set of customers, which also takes the excess strain off the engineering resources.
Q: Is it possible to do a multi-stage update – move a pilot batch of customers to the new release and perform a mass migration of all remaining customers at once?
A: Nothing prevents you from doing so. The limitation will be in the speed – how fast Porter can move the customers – but if you only have a few thousand customers, this can be done pretty quickly. However, this way, you will lose all the advantages of dealing with possible customer issues gradually. So this is doable, but it diminishes the benefits of the Dual Version technology.
Q: Will it be possible to send API calls in the format required by the new version and have the web dispatcher “translate” the API code to the syntax required by the old version if the target customer has not yet been migrated?
A: The web dispatcher doesn’t translate the API requests as such, but it does forward them to either the source or the target system. We expect the old code that worked seamlessly with the old version to work seamlessly with the newer release as well, because the code will be sent to the new version and then returned (unless there is some backward compatibility issue). The new code will work best with the new version because the previous version might not supply all the required data. This will be covered in detail in our API guide for developers.
Q: Which major releases will be available as migration targets, and what’s the likely delay time?
A: We need to test the process of migration to a specific release in our lab before we can offer it to our clients, to ensure that the data transformation and everything else is working correctly. Then we’ll have metrics of already supported releases. In a perfect world, a new release – for example, MR90 – would become available for a Dual Version migration within a month after the release date.
Q: Are extra servers required for Dual Version?
A: Yes, Dual Version must run on a physically separate system. This is the only way to allow your current source system to keep running and serving your customers during the update. You can opt for a separate set of physical hardware in a data center or use our cloud system. The cloud can be a temporary migration tool, or you can use this as an opportunity to liberate your operations from the physical data center permanently. In our opinion, the cloud is the way to go forward and future-proof your operations.
Q: How many servers do I need for the target system?
A: As many as is sufficient to handle your load and the number of customers that you have. The exact number is defined during the pre-migration check. Please remember that the cloud option is also available. This may be the best solution for you, especially if you only consider Dual Version for a one-time migration to get to a recent release (and you’re not sure you’ll be using it full-time).
Q: How does using the Dual Version for migration influence the license fees? Do I need to buy an extra license?
A: An extra system does require licensing. You can purchase a regular perpetual license and use it for your target system in Dual Version or as a separate system to ensure redundancy – that’s up to you. If you’re only interested in extending the system for a one-time Dual Version migration, we can come up with an exclusive license to cover this situation. Talk to our Sales Department to arrange this.
