A cloud implementation methodology for legacy apps
Maximizing the benefits of cloud while minimizing risk requires a fine-tuned migration strategy. Here, Scott Lowe lays out a cloud implementation methodology for legacy apps.
Cloud computing is shaping up to be one of the most disruptive phases in modern IT. More than a decade into the great cloud migration, technology leaders continue to be bombarded with constant promises of cloud-induced IT transformation. But there are myriad challenges that CIOs and other decision-makers need to overcome in order to develop a cloud strategy that meets business goals while minimizing organizational risk.
In this article, I focus on a cloud implementation methodology for legacy applications, explaining the common benefits and potential pitfalls of these kinds of migrations.
Legacy application migration
A cloud implementation methodology focused on legacy apps assumes two things: that the business of the company runs on applications, and second, that it has been doing so for quite some time -- hence the emphasis on legacy.
A common approach to moving legacy apps to the cloud is to base cloud implementation decisions on the needs of individual applications. However, the assessment of individual apps can't be done in a vacuum. User and organizational needs must also be taken into consideration. For example, if you've moved a client-server application to the cloud without fully thinking through how users interact with the application, user angst will be high and productivity may suffer, which can put at risk future application migrations. In an ideal world, application migration projects will be largely invisible to users.
Application architecture
While application architecture is a technical consideration, it's also one that impacts users when such applications are migrated to the cloud. For example, consider a traditional client-server-based ERP system, which are far from dead in many companies. Simply pushing that application to the cloud -- sometimes referred to as a "lift-and-shift" operation -- could have disastrous consequences for users if appropriate connectivity decisions don't accompany the migration. Most database applications deal poorly with network latency and shifting just the server side of a client-server application to the cloud will increase latency, often beyond tolerable levels.
To combat this, you might consider also deploying remote application access tools -- such as Citrix or Microsoft's remote desktop services -- in the cloud provider environment so that all operations remain local, at least from the perspective of the application. Doing so does increase the cost and complexity of the cloud migration, though, so you'll need to review your cloud total TCO calculations to make sure that these additional services don't result in a net increase in expenses.
An illustration of the benefits of cloud applications
To be clear, I recommend moving traditional applications to the cloud only if there is an obvious benefit. These types of applications were designed with private data centers in mind and, in general, the need to rebuild so much surrounding infrastructure in the cloud can often negate financial and simplicity benefits.
That said, for many, there are still benefits to be had -- from operationalized economics and improved simplicity to instant scalability -- and, as such, you'll need to figure out your process.
Deciding on a migration process
To move legacy apps to the cloud, you can simply copy and paste the existing application environment, or you may fully rebuild the environment from the ground up at the cloud provider. If speed of deployment is your primary concern, copying local virtual machines to the cloud and restarting them at the provider will yield the best outcomes. Again, as stated earlier, there may be additional complexities due to surrounding infrastructure.
Legacy app migrations are often really good opportunities to clean up, too, and ensure that the application operating environment adheres to today's best practices.
However, legacy app migrations are often really good opportunities to clean up, too, and ensure that the application operating environment adheres to today's best practices rather than the ones that were in place when the application was deployed.
Where it makes sense, you should rebuild application services in the cloud rather than just copy them from the local environment. Budget and organizational goals will help you determine if this step makes sense.
To cloud or not to cloud
Any cloud implementation methodology requires that you make decisions about which applications you want to move to the cloud and in what order. Very few organizations will be able to simply migrate everything all at once, so some prioritization has to take place. So, where do your begin?
Low-hanging fruit
Start with low-hanging fruit that has low impact on the organization. Find services that aren't used often or that are used only lightly and may not be mission-critical. Move those first to help both you and your staff learn about the overall process and learn lessons that can be applied to more critical workloads. Through this process, you will learn about how the cloud provider supports your workloads so that you can make appropriate adjustments as you move on to the next wave of your application migration.
Consider SaaS
Wherever possible, migrate appropriate services to SaaS vendors. For example, if you're an Exchange shop, consider a move to Office 365 or an equivalent. For many companies, it simply no longer makes sense to operate local collaboration environments. But, there are exceptions. If you're running a heavily customized environment, make sure you do a feature-by-feature analysis to determine what you may lose and then decide if the company can live without that feature. If not, either find a workaround or stay local.
Likewise, you might consider replacing some of your local data analysis services with cloud-based ones. With the ability for many cloud-based reporting services to scale to almost unlimited capacity, you won't have to worry about local compute and storage resources for something that is becoming more important all the time.
What should stay local
Finally, your cloud implementation strategy must account for those applications that need to stay in the local environment. Infrastructure support services, such as DNS, DHCP (Dynamic Host Configuration Protocol)and print servers, really need to stay local, and you will need to keep at least one or two domain controllers local for authentication purposes.
Beyond these basics, though, consider keeping applications that are particularly mission-critical, sensitive, or that are highly regulated in-house. Even if you can find a capable cloud provider, many prefer to keep such services under local control as a part of a risk management strategy. This too, however, is starting to change as cloud providers continue to deploy increasingly robust and secure environments. Over time, security, data locality and regulatory concerns related to cloud deployment will be a thing of the past.
About the author:
Scott Lowe is a former CIO and frequent contributor to TechTarget, TechRepublic and other IT publications. He is the founder and managing consultant of The 1610 Group. Follow him on Twitter @OtherScottLowe.
