Landing a commercial aircraft looks deceptively simple from inside the terminal. The plane descends, touches the runway, and taxis to the gate. But a safe landing depends on preparation that happened long before the wheels touched down.
The runway has been cleared. Weather and wind conditions have been assessed. Air traffic control has coordinated the approach. Crews know their roles. Emergency procedures are ready, and alternate plans exist if conditions change.
Cloud migration can create a similar illusion of simplicity.
From a distance, moving an application from an on-premises environment into AWS, Azure, GCP or other cloud platforms can look like just a change in hosting. Yet many organizations are beginning to discover how misleading that assumption can be. Recent research has found 70% of CEOs say their organizations arrived at their current cloud environment “by accident, rather than by design.”
That distinction between simply arriving somewhere and arriving prepared is central to how Axian Solution Architect Todd Parker thinks about cloud migration.
In a recent conversation, Parker offered a straightforward piece of advice for engineering leaders:
“Treat this as a major architectural change.” The apparent simplicity of cloud migration can obscure how much of an application’s behavior depends on the environment underneath it. Network characteristics change. Performance assumptions change. Operational requirements change. In Parker’s words, once that architecture changes, “every single piece of my system is affected.”
The objective, then, is not merely to get an application into the cloud. It is to prepare an environment where that application can land predictably, perform as expected, and remain recoverable when reality inevitably introduces something the migration team did not anticipate.
Cloud Migration Changes More Than Your Hosting Bill
Cloud migration is sometimes framed as a change in where an application runs. An organization operates its own infrastructure or pays a data center provider today, moves its workloads to Azure or AWS tomorrow, and begins paying a different vendor for many of the same underlying capabilities.
This framing makes the transition sound simpler than it is.
Moving an application to the cloud changes the environment the software was built to operate within. Network characteristics may differ significantly from those in an on-premises data center. Response times may increase while available throughput improves. Services that once communicated across a fast local network may suddenly encounter latency that was never important enough to consider when the application was designed.
These differences can expose assumptions buried deep within mature software. A particularly “chatty” application, for example, may make frequent calls between components without consequence when everything resides on the same local network. However, move those components into a different architecture, and the same communication pattern can become a performance problem. In other cases, teams may compensate by purchasing additional compute or networking resources, allowing the application to function while driving cloud costs substantially higher than anticipated.
This does not mean that every component must be rewritten before an application can move. Lift-and-shift migrations can be entirely appropriate when speed is the priority. But organizations should recognize the tradeoff they are making. Cloud migration changes network behavior, performance characteristics, failure modes, infrastructure economics, and operating assumptions simultaneously.
Understanding those changes before migration is what turns a new hosting destination into a viable landing zone.
A Landing Zone Is More Than Somewhere to Put Servers
A successful landing requires more than reaching the destination. The early space programs demonstrated that distinction rather dramatically: hitting the Moon at near-cometary speeds and landing an intact spacecraft on the surface were two very different engineering achievements. Before workloads begin moving, organizations need to know how to keep landing conditions within workable tolerances.
This is the purpose of a cloud landing zone. It provides the shared infrastructure and foundational controls applications will depend on once they arrive, including:
- Networking
- Identity and access controls
- Security policies
- Logging and monitoring
- Mechanisms teams use to provision and manage cloud resources
A landing zone, in other words, is not simply a destination. It is an operating environment.
Parker emphasizes that this environment should be validated against the specific applications it will eventually support. “Make sure that your landing zone has been completely built out and has been tested against your application,” he explains. This means doing the work before customers are moved and using production-worthy resources so testing reflects the conditions the application will actually encounter.
The financial stakes make that preparation especially important. A recent survey of 759 cloud decision-makers and users found that 84% of organizations considered managing cloud spend a top challenge, while organizations exceeded their public-cloud budgets by an average of 17%.
Poor landing zone readiness can contribute to exactly this kind of operational inefficiency. An application may technically function after migration while requiring additional compute or networking resources to compensate for architectural assumptions that no longer fit its environment. Parker notes that organizations pursuing a rapid “hard landing” can sometimes accept that tradeoff, but they should understand what they are buying and why.
A production-ready landing zone creates the opportunity to discover these issues earlier. Teams can test networking behavior, validate monitoring and infrastructure, harden controls, and identify where existing application assumptions conflict with cloud-native architecture before those conflicts become customer-facing problems.
Soft Landings Require Discovery Before Migration
Landing zone readiness addresses one side of the equation. Organizations also need to understand what the application itself will require once it gets there.
Much of this work begins with discovery. Before migrating a workload, teams should understand its existing network profile, including:
- How much data moves between components
- How frequently those components communicate
- What levels of latency the application tolerates
- How much throughput it requires
These characteristics may have developed over years in an environment where the underlying infrastructure made them largely invisible. Cloud migration can expose them quickly.
An application built around frequent communication between services may perform well when those services sit close together on a local network. Introducing additional latency between them and thousands of individually insignificant interactions can become a noticeable performance problem. Conversely, a cloud environment may offer greater throughput or managed services that create opportunities to improve the architecture rather than simply reproduce what existed before.
For Parker, this is why discovery should happen before migration rather than as troubleshooting afterward. The upfront work, he explains, is about “making sure that you know what you’re getting into” and confirming that the new environment is capable of handling the application as intended.
Discovery does not always mean fixing every issue before moving. Sometimes business requirements make speed more important. Parker describes a current client with a mandate to move into Azure quickly, where the appropriate strategy is essentially to lift and shift first and compensate for some network inefficiencies with additional spending while the architecture evolves.
The important distinction is whether those compromises are deliberate or discovered later by accident.
A soft landing does not require eliminating every uncertainty before migration. It requires identifying enough of the application’s operating assumptions to understand where problems are likely to emerge, what tradeoffs the organization is accepting, and which behaviors need to be watched most closely once real workloads begin moving. Discovery establishes a baseline. Testing determines whether the assumptions behind that baseline survive contact with the new environment.
Confidence Comes from Testing, Not Hope
Even thorough discovery cannot identify every problem a cloud migration might expose. Applications are too complex, production environments too variable, and mature software too full of accumulated assumptions for teams to predict every possible outcome in advance.
Parker argues that the answer is not to eliminate uncertainty but to design the migration around it.
One approach is a blue-green deployment, in which the existing environment remains operational while the new cloud environment begins receiving a limited share of production traffic. Instead of moving every customer at once, a team might start with 1% of users and observe how the application behaves under real conditions. If something unexpected appears, traffic can be shifted back while the problem is investigated.
As confidence increases, so can exposure. Depending on the application and the organization’s risk tolerance, teams might move 10%, 50%, or some other share of traffic before deciding the new environment has demonstrated enough stability to become primary. Parker stresses that there is no universal threshold. The purpose is to create evidence that the application works as expected without making every customer part of the experiment.
This is also why rollback capability matters. As Parker explains:
“You always want to have that backup plan to go back to home base.”
The alternative is a hard cutover, where an unforeseen problem can immediately affect the entire user population. And unforeseen problems are inevitable. “You can never have full 100% confidence that it’s going to work flawlessly,” Parker notes. Even long-lived applications can contain bugs that remain dormant for years until a new environment finally exposes them.
Testing therefore is not about proving that nothing will go wrong. It is about reducing the consequences when something does. A soft landing preserves options. Teams can observe, learn, adjust, and, when necessary, retreat before attempting the approach again.
The Goal Isn’t a Faster Migration. It’s a Better Landing.
Migration programs naturally create pressure to show progress. Leaders want workloads moved, legacy infrastructure retired, and the benefits of cloud investment illustrated in a slide deck as quickly as possible. From that perspective, spending weeks testing an environment while continuing to pay for existing infrastructure can look like an expensive delay.
Parker argues that organizations should evaluate that expense against the risk it is designed to reduce. Running environments in parallel, testing with production-worthy resources, and maintaining rollback capabilities all cost money. But, as Parker puts it, “It’s not waste to spend.” That additional investment creates time to identify problems before the organization becomes dependent on the new environment.
Major cloud providers increasingly frame migration this way. AWS divides its migration process into three phases: assess, mobilize, and migrate and modernize. Its Cloud Adoption Framework evaluates readiness across six dimensions:
- Business
- People
- Governance
- Platform
- Security
- Operations
During the mobilize phase, AWS recommends creating target architectures and testing the migration environment with smaller or less critical applications or services before broader migration begins.
Speed at one stage does not necessarily translate into a faster migration overall. A rapid cutover followed by performance problems, emergency architectural changes, unexpected cloud spending, or a difficult rollback can quickly consume whatever time the organization saved upfront.
The better measure of progress is therefore not simply how quickly workloads leave the existing environment. It is how reliably the organization can move them without creating new operational problems in the process.
This brings the landing metaphor back into focus. A successful approach is not judged by how quickly an aircraft reaches the runway. Success means arriving under control, within safe operating conditions, with alternatives available if circumstances change. Shaving time off the approach has little value if doing so makes the landing less predictable.
Cloud migration should be judged by the same standard.
Prepare for the Landing
Cloud migration may be easier than ever to initiate but technical accessibility does not make the underlying architectural change any less significant. Applications bring years of assumptions about networks, infrastructure, performance, and operating conditions with them. Moving those applications successfully means understanding which assumptions will survive the journey and preparing for those that will not.
That is why Parker’s advice to “treat this as a major architectural change” is ultimately less a warning than a useful starting point. Preparation does not require eliminating every possible source of failure. It means understanding the application, preparing the landing zone, testing under realistic conditions, and preserving a route back when the unexpected occurs.
Cloud migration is not just a move. It is a landing that has to be prepared. If your team is planning a migration, Axian can help make the landing zone, testing strategy, and rollback path more predictable before workloads depend on the new environment.
Facing cloud migration challenges? Contact Axian to start the conversation.