This article reviews the technical realities of ‘zero downtime migration’ in the cloud, detailing the processes that back up such a claim, if any, as part of a broader look at cloud migration. There are a number of vendors that use the term ‘zero downtime migration’ in their marketing. However, many are not able to explain the logic behind this claim. Providing this breakdown will allow potential customers to analyze vendor claims and determine whether a vendor has the technical means to provide a ‘zero downtime migration’ or if the claim is merely marketing.
Marketing Phrase vs. Technical Commitment
Traditionally, ‘downtime’ describes the time during a migration when a service is unavailable. Because of this, the term ‘zero downtime migration’ should not be used to describe a migration where no unplanned service outages occur. Rather, it should refer to a migration where the service is continuously available using a cutover or replacement of the service — the basis of a real cloud cutover strategy. Providing a ‘zero downtime migration’ should not be used to make a guarantee by a vendor about service availability.
What Providing 'Zero-Downtime Migration' Means
There are a number of steps that must be taken to facilitate a true ‘zero-downtime migration.’ These include running both the old and new versions of the service, continuously keeping the data in the two versions synchronized, validating the replacement service, and finally having a service replacement plan to rollback the service to the previous version if there is a problem with the replacement service. If any of these steps are not taken, there is a risk of a service outage which is why a documented migration rollback plan matters so much.
Phase 1: Assessment and Dependency Mapping
This phase involves identifying all dependent systems and applications and the server migration environment, including less obvious dependency (e.g. task scheduler, inter-service communications, and off-server, e.g. cloud, workload processors). Migrations frequently result in unexpected downtime. One of the most common causes of unexpected downtime is failing to identify a dependency. Dependencies, especially less obvious ones, are usually not documented. This is the starting point of any well-run phased cloud migration.
Phase 2: Parallel Environment Configuration
The focus of this phase is construction of the new (cloud) environment. During this construction, the existing (on-premises) environment is left un-modified. Construction of the new (cloud) environment does not impact the existing (on-premises) environment. This is referred to as “building in parallel” in the migration literature the core of the parallel running migration approach.
Phase 3: Data Migration
Continuous data synchronization from the existing (on-premises) environment to the new (cloud) environment is the focal point of this phase. Data migration is completed during the synchronization. This allows the new (cloud) environment to be switched over to production, and the switch-over to be completed without any data latency.
For related continuity planning, see our Backup and Disaster Recovery guide on protecting data during transitions like this.
Phase 4: Functional and Non-Functional Testing
Prior to data migration and environment cutover, the new (cloud) environment is tested. Functional tests are completed to verify the correct operation of the applications. Non-functional tests (performance tests) are completed to validate the new (cloud) environment can support the production load. Once testing indicates the new (cloud) environment is ready to support production workloads, a limited group of end-users are given access to the new environment to complete production work a critical stage of cloud migration testing.
Phase 5: Cutover
Although the goal of a migration is to minimize disruption to business processes, it is standard practice to time the cutover for a period of low network load, such as the weekend. At this point, the DNS records are updated to direct users to the new environment, and the old environment is kept online for a short time to ensure availability in case of an error.
Phase 6: Rollback Plan
Validation testing is intended to catch as many defects as possible, but there are some defects that only become apparent after migration, at which point a quick rollback to the old environment is essential to implement a true zero-defect migration strategy. Providers that do not have rollback processes in place indicate that zero-defect migrations are not really a strategy one of the clearer cloud migration best practices to insist on.
Scenarios to Consider
There are a number of risks involved in migrating data, and although a given migration may reduce the risk to an acceptable level, complete elimination of risk is not possible. Examples of risks that remain after a migration include undefined dependency, unexpected volume of migrated data, and behavior of integrated systems and components in the migrated environment. Understanding this cloud migration risk upfront is central to protecting business continuity migration outcomes.
How Ovron Inc. Achieves Zero-Downtime Migrations
Ovron Inc. doesn’t rely on exaggerated marketing claims to increase their client base. Their team of developers have the ability to migrate clients from on-premise environments to the cloud using a cloud migration process that implements a validated rollback plan for each migration phase, giving clients a migration process they can view and understand. Ovron Inc has the ability to implement a black-box migration process.
For questions to ask any technology vendor before signing, see our IT Consulting Due Diligence guide.
Frequently Asked Questions
True zero-downtime processes cannot be guaranteed because there are always external factors which are beyond the control of the service provider. Depending on the client environment, and with adequate planning and execution of migration processes, the disruption to the client’s business can be significantly reduced.
Ask the service provider to explain the steps they take when migrating data to the parallel environment, the means they take to ensure the integrity of the data, and the methods they employ to validate the correctness of migrated data. A service provider who employs true zero-downtime processes will not have a problem explaining the above to a client.
This largely depends on the size and complexity of the overall migration. This phase of the migration tends to take the most time and longer overall migration duration is generally attributed to the time needed to synchronize and validate data.
Once data is synchronization cutover occurs to direct users to the new system. Defects in the migrated data can lead to unexpected issues and to ensure high availability to the business, migration plans typically call for rollback to the prior state if such an issue occurs.
Summary and Next Steps
A migration without a planned rollback is potentially putting the business at risk. Potential cloud migration partners that state they perform rollbacks should be further assessed and migrating partner’s processes should be further defined.
Ovron Inc. can provide migrating partner’s processes, solutions, and services for your next cloud migration. Contact us to Learn More.
Ready to fix this for your business?
Table of Contents
