Failover
Here is an important question that arises: whether the failure has actually been tested or simply documented?
This is the process where most of the mission-critical application migration projects are silently gambling. For instance, the British Airways’ 2017 outage is a stark example of this situation. A data center power failure at Heathrow resulted in traffic when power was restored. The airline released a statement declaring a total loss of power, followed by an uncontrolled restoration that physically damaged servers.
Fortune reported that this incident resulted in roughly stranding 75,000 passengers and grounding flights across two major airports. But reporting this incident on time led to immediate resolution of the problem, which was to take down the airline’s failover systems along with the primary ones.
Here are some questions that CIOs should ask their team:
- Does a failover system that exists on paper actually practice under real failure conditions?
- When was the failover tested? Was it a scheduled drill, or was it tested under simulated real-world failure, not a scheduled drill?
- Does failover on the new platform match or exceed current uptime guarantees?
Recovery
Failover and disaster recovery are related but distinct. Recovery objectives (RTO and RPO) define how much data loss and how much downtime the business can tolerate after a major site or regional failure.
Here are some questions that CIOs should ask their team:
What is the current status of your RTO and RPO commitments for this workload? Do the projected numbers for the new infrastructure match?
Has disaster recovery (DR) already been tested with the factual data restoration and application restart?
What is the time duration for a complete recovery from backup or replica under realistic conditions?
What is the plan when the primary recovery site is compromised?
Supportability
The declining experts who have a clear understanding of legacy systems are one of the primary reasons why the modernization of these existing systems is a success. But now the same question is applicable to the new platform. There is a shift not only in the vendors but also in in-house skills; it takes time. This new platform that looks compatible with the current mission-critical workloads may not be supported in a couple of years if there are challenges in transitioning.
Here are some questions that CIOs should ask their team:
- Who offers the long-term support for the new infrastructure, and what’s the vendor’s roadmap for mission-critical application migration?
- Do the IT team and engineers operating on the new infrastructure have a clear understanding of the new environment?
- What is the expected support window for both hardware and software workloads?
- How will knowledge transfer and runbook updates be managed?
Portability Options for the Future
It is important to understand that each decision regarding mission-critical workload migration either minimizes future vendor lock-in or just trades one form of lock-in for another. There are cases seen where a new platform may solve today’s challenges but may create a new
Every migration decision either reduces future lock-in or trades one form of lock-in for another. A platform that solves today’s problem but creates a new equally rigid dependency. So, you can say the actual problem is not resolved but just deferred for the time being.
Here are some questions that CIOs should ask their team:
- Does the new infrastructure make the mission-critical application migration process easy and simple?
- Is the critical workload tied to proprietary formats or APIs that can limit future innovation options?
- What would it take to move this workload again in five years?
- Is the mission-critical workload migration cost acceptable or not?
Why Turning This Checklist Into a Formal Assessment
The checklist contains seven categories that work best as the backbone of a structured framework for workload migration assessment. It is not just a simple one-time conversation but requires the involvement of both IT and business stakeholders, documenting answers rather than making assumptions, and revisiting the assessment after the evolution of migration timelines.
Discarding a checklist after a mission-critical application migration makes it no better than having no checklist, especially if it is never reviewed later. The assessment should result in a written risk register but not a simple verbal sign-off. This helps give visibility to the gaps in compatibility, dependencies, or recovery planning to everyone.
Seamless Mission-Critical Workload Migration with Stromasys Charon Emulation
Charon emulation is a cutting-edge solution from Stromasys that seamlessly moves the critical workloads from the outdated infrastructure to a new one without any code changes, re-certification, or data migration risks.
The Charon emulator mimics the behavior of the current legacy infrastructure on a new modern platform so that critical workloads and OS can continue to operate without any disruptions. It preserves the existing business logic while leveraging the benefits of a new, modern platform. This enables better DR, compatibility, scalability, and efficiency while reducing costs.