Key Cloud Migration Decisions

Most legacy applications have implicit assumptions about operating systems, hardware, geography, latency, throughput, scalability, governance, access rights, monitoring and other aspects that must be carefully addressed before deploying to the public cloud.

by Alex Veytsel, Steve Lerner and Tony Greenberg

as published by Microsoft TechNet

When faced with the many opportunities afforded by a cloud infrastructure—on-demand scale, potential cost reductions, elimination of complex maintenance processes, etc.—the decision to build a new application in a public cloud is often a no-brainer, especially for the buyer with the mindset of prioritizing agility and speed-to-market over customization and the perceived security/reliability advantages of internal infrastructure.

Migrating an existing application, however, is a different beast. Most legacy applications have implicit assumptions about operating systems, hardware, geography, latency, throughput, scalability, governance, access rights, monitoring and other aspects that must be carefully addressed before deploying to the public cloud. Some of these have been addressed through the experiences of adapting these applications to function correctly in a private cloud, but the provisioning of shared resources in a public cloud remains a more difficult leap.

Migration Decisions

· · ·When deciding whether or not to migrate existing functionality to the cloud, the decision criteria are more complex than for new builds. Key questions in “cloud planning” include:· · ·

• Should I migrate to a public cloud (and if so, which one), or a private cloud within my existing data center?
• How can I tell if my application can be moved to the public cloud at all? Should I engage in an application remediation strategy to accommodate such a move or rebuild from scratch?
• Should I hybridize my application to move some part of functionality to the public cloud while keeping other components on an internal private cloud?
• When should I consider public cloud SaaS solutions for my end-users, and how should I approach the build? If so, is portability across multiple heterogeneous clouds important for my application and how can it be achieved?

For those enterprises that are just beginning their journey and not yet ready to tackle the full depth of analysis needed for migration, we offer a few rules of thumb for the first few questions above. However, it should be noted that this is only the first step. For organizations with large application portfolios, it is important to go beyond these rough guidelines and establish a consistent scoring and evaluation across disciplines and departments, so that they can effectively prioritize those best suited for cloud migration. More thorny issues of formalizing these rules as well as dealing with governance issues of regulatory constraints, security restrictions, access rights, and SLA commitments often wind up being solved with another technology layer of planning and governance software.

Public Cloud vs. Private Cloud

Many of the advantages of the public cloud can be achieved with a private cloud capability as well — by deploying similar mechanisms used in a public cloud, but within the existing data center and implementing an on-demand, API-driven orchestration layer. Key criteria that would lead buyers to choose this approach instead of public cloud include:

• Predictable Demand — if you know what amount of compute capacity and storage you will need a year from now, you can provision virtual or even dedicated servers to meet the demand. If every month brings new surprises, private cloud deployments can prevent overprovisioning waste or under-provisioning congestion, not to mention the stress of hitting tight deployment windows.
• Consistent Demand — for services that have the same amount of volume each hour, day of the week, and each month, a private cloud deployment may make sense. The same goes for those whose divisions have that peaks are asynchronous enough to benefit from optimizing utilization among disparate user groups. When considering projects in industries like retail (with a Black Friday spike and a broader December plateau) or online games, where winter weekends spike demand, the public cloud becomes more attractive.
• Tight Coupling Between Apps and Devices — if an application is tightly integrated with other applications or hardware (such as network attached storage devices) that you are not yet ready to move to the cloud, it may encounter latency issues or other problems when moved by itself. A private cloud deployment will help mitigate this issue.
• Specific Network Access — if applications are required to access specific networks for connection to clients, offices, or other network dependent entities, private cloud may be the only choice due to the ability to deploy hardware on a specific network or mix of networks.

How to Diagnose Moving Difficulty

In our experience, the customers that could benefit the most from moving to the public cloud were often the ones least able to do it due to core assumptions in the design of their applications. Some of the ones we have seen in the past include:

• Hard-coded Geography and Network Topology — applications may have implicit assumptions as to where they are on the network and in the world. Hard-coded IP addresses are the easiest example, but other decisions may assume geographic or network hop proximity to resources that the cloud instance will no longer have nearby.
• Tight / Undocumented Latency Needs — in designing data center deployments, we have worked with buyers whose SAN needed to be no further than 20 feet away from their servers because their applications would time out otherwise. In a cloud environment, even if your storage is in the same location (not always guaranteed), it may be a mile away in the same data center campus.
• Extreme Throughput — many cloud storage providers shy away from high performance database storage altogether because of an inability to hit IOPS targets. Even services ostensibly designed to support databases don’t always offer the consistent high throughput of dedicated hardware. Applications built on high-performance throughput assumptions may not be able to adapt to the more variable – if not outright lower – performance of their cloud instance.

If your application faces multiple constraints such as the one above, it may be worth it to look to the next generation and build for the cloud in the next major release rather than try and adapt existing functionality built on the assumptions of certain latency, throughput, and location.

Hybridizing Apps

Another interim step is “hybridizing” an application to run some instances or functionality in the public cloud while retaining the core on an internal private cloud. Key decision criteria that would make this approach desirable include:

• Limitations in Existing Infrastructure — a hybrid approach is often useful to overcome specific gaps in the original design. For example, if a company has a single data center on the West Coast of the U.S., a public cloud extension or instance can better serve customers on the East Coast or in Europe while retaining centralization / synchronization to the master database.
• Low Cost Added Availability — a Tier IV data center can cost up to 50% more than a Tier III data center while offering only 1.2 more hours of uptime annually. So when your app must be available 24x7x365, a light version of an app hosted in a public cloud that can hold down the fort during datacenter outages or maintenance can be a life saver at a fraction of the cost of extra redundancy.
• Event-Based Demand Spikes — if your spike demand (say due to a promotion or media coverage) is different from your regular demand profile, it may be possible to build functionality just for that extraordinary bulge in the public cloud, trading in some performance for extra flexibility. The interface or functionality or response time might be a bit off, but your one-time spike users will never notice.

The Final Step: Migrating Apps to SaaS

The last key migration question is when to make a more wholesale change from a client application to software as a service (SaaS), and if so, how much to rely on pre-built functionality of a PaaS or SaaS vendor rather than developing in house. Rather than a classic migration dilemma, this is more of an architectural decision, and is made at a more strategic level based on the following questions:

• What’s Less Predictable: Configuration or Access? — the bane of the desktop application is the plurality of desktop hardware and software configurations and the possible conflicts this engenders. If the desktop is not locked down, client-side apps are harder to build and support than browser-based apps. Conversely, if access to the internet is more inconsistent, then SaaS often runs into problems absent client-side workarounds, while local apps work better.
• Can I Support Constant Releases? — a major advantage of SaaS approaches is the constant addition of incremental functionality. If developing significant functionality in-house but without tight QA controls, this advantage can turn into a liability quickly, as bugs are introduced along with new features on a weekly or monthly basis. The discipline of the development process becomes key.
• How Much Lock-In Is Acceptable? — IaaS approaches, while not perfectly interchangeable, can be switched with relatively little pain. PaaS and SaaS platforms are much easier to get started on but may be much harder to leave. If Microsoft or salesforce.com is a strategic vendor that you trust implicitly, the tradeoff is worth it. If you envision changing platforms down the road, a more generic approach may be better.

Key Cloud Migration Decisions – Conclusion

The decision to choose public or private cloud-based solution is not trivial even for new builds — a stigma of risk still hovers over the industry given outages at some public cloud vendors. When migrating existing applications, the risk threshold is even higher and buyers still often choose to only dip their toes by virtualizing within existing data centers or building extensions in the cloud while keeping the core as it was.

As public cloud technology matures, the aspect of risk will start to fade away. What will remain is the tradeoff between easy / rapid scale on one hand and customization / control to accommodate application-specific environments on the other. And as connectivity becomes more ubiquitous, and development discipline reduces the need for fine-tuning hardware, all three flavors of public cloud: IaaS, PaaS, and SaaS, will become increasingly viable targets, not just for new apps, but for migration of legacy functionality.

Between The Steel and The Ether: On The Threshold of The Cloud

The world you know is built on sand, but the next one is being woven from light and logic. We are living in the hinge years, a time between the tangible and the abstract, where the very foundations of our digital civilization are being ripped up and replaced. The migration to the cloud is not a technical upgrade; it is a spiritual and structural inflection point. It is the digital equivalent of leaving the old country for a new continent, and it demands of us a new kind of courage, a new kind of sight.

I remember the server rooms. The low, constant hum was a mantra of power, the air thick with the heat of processing, smelling of ozone and hot metal. You could lay a hand on a server rack and feel the vibration of the world's work, a physical pulse. I recall the heft of a 2U server, the satisfying click of the latches as you slid it into the rack, the precise geometry of bundled cables. It was all there, solid, heavy, real. Now, we are asked to trade this for an abstraction, for a line of code that summons resources from a data center a thousand miles away, a campus so vast it generates its own weather, cooled by the same river that once powered a different kind of industry.

The choice is no longer about owning the steel. It is about understanding the architecture of this new world. The public cloud is a utility, a planetary-scale grid of computation, but it runs on the rails of venture capital and market logic. It offers unimaginable scale at the cost of a subtle but profound dependency. We are trading the known limitations of our own hardware for the opaque complexities of a shared infrastructure. This is a systems-level shift in power. The decision to migrate an application is not about IT budgets; it is an economic and political decision about sovereignty, resilience, and the kind of digital world we want to inhabit. Are we building on a foundation we control, or are we renting a floor in someone else's skyscraper?

I confess, there was a fear in letting go. A deep, guttural anxiety in decommissioning the last physical server for a core application. It felt like abandoning a ship that had carried us safely for years. Was this faith in the cloud a form of wisdom, or a form of abdication? I longed for the certainty of the blinking green light, the physical assurance that our world was still running. To release that, to trust the ether, was an initiation. It was an act of surrendering the illusion of absolute control to gain the freedom of movement, and I was not entirely sure we were making the right bargain.

The future is built on invisible foundations.