Contents:
Ever since cloud computing became something more than an academic icebreaker, companies have sought to reap its benefits. One of the many innovations of cloud computing is cloud migration or the process of moving applications, databases, and business architectures to a (third-party) cloud environment.
Obviously, there are several benefits to migration on cloud – decreased latency, fewer costs increased security, and a level of flexibility that would have, otherwise, been unattainable through physical means (i.e. a corporate network infrastructure spanning hundreds of servers, routers, cables, connectors, and whatnots).
Cloud migration is here to stay and, sooner than you realize, you’ll start researching things like “AWS”, “Azure”, “Google Cloud”, or “Cloud migration tools”. To spare you the trouble of spending countless hours looking for cloud migration-related topics, I have created this small, but comprehensive guide that will, hopefully, help you make an educated decision about ‘clouding’ your business.
What is cloud migration?
The answer to this question is twofold – moving physical assets and software. It’s fairly easy to understand how software can be ‘virtualized’, but what about physical assets? In cloud migration, networking equipment such as routers, physical firewalls, and miles of cables, get discarded in favor of a cloud-hosted infrastructure.
The first step in migrating the infrastructure to the cloud is to ascertain what kind of equipment can be jettisoned. So, it would be in your best interest to keep an updated networking gear inventory, from switches to bridges, multiplexers, transceivers, and hubs. One word of advice, though – never, ever scrape off your on-premises backup servers.
Many SaaS, PaaS, and CaaS operators offer DLP (Data Loss Prevention) solution, but, as you would imagine, those backups would no longer be in your hands. Better safe, than sorry, as we always like to say in cybersecurity.
Now, as far as the second part of the issue is concerned, there’s quite a lot of controversy floating about. Some say it’s merely a matter of ditching some apps, getting new ones, and firing up the cloud-hosted architecture. In an ideal world, that statement would probably be true. Since we live in a less-than-ideal one, it’s only fair to surmise that app and software migration is a complex procedure.
Legacy software and initial evaluation
At this point, I think we should discuss legacy software in the context of the cloud migration process. I won’t go into more technical details, since my colleague did a bang-up job describing the ins and outs, pros and cons of legacy software.
Be sure to check out her article before going any further. All you need to know is that legacy software can still be used to carry out some of your more mundane tasks, but, due to their nature, they pose significant security concerns. Please keep that in mind when drafting your cloud migration plan.
Back to the planning part – there’s no room for error here. That’s why establishing a migration flow should be your first order of business.
Building an actionable migration flow can be as easy making a shopping list:
- Define purpose.
- Evaluate costs and needs.
- Choose a cloud environment.
- Choose a deployment plan.
- Select an architecture.
- Deploy and enjoy
or as intricate as the diagram below:
Courtesy of GlassHouse
So, everything’s fine and dandy, but how do you migrate your assets to the cloud? Let’s discuss all the steps involved.
A) Evaluate the perspective
You will need to take the high road on this one. Before taking any course yourself of actions, consider all the factors involved: costs, benefits, requirements, security, and an auxiliary plan in case something happens during or after the hand-over process is completed. Why a hand-over and so many checkpoints along the way?
Well, because you’re literally outsourcing a big part of your company. As I mentioned, cloud migration is a twofold process – hardware and software. The software part involves company-sensitive information (i.e. databases filled to the brim with client or partner data). You really wouldn’t want that kind of info falling into the wrong hands, do you?
According to Amazon’s AWS Cloud documentation, the cloud migration assessment/evaluation phase has the following components:
TCO calculation
The financial assessment phase; TCO (Total Cost of Ownership) is an estimation of the total expenses which are usually associated with buying, maintaining, and operating a product. As part of the financial assessment phase, TCO helps you figure out if the product – which in this case is the cloud service – is worth the investment or not.
There are plenty of online tools that can help you figure out the TCO quotient, even one created specifically for Amazon’s AWS. Still, if you’re one for pen-and-paper, here’s the math formula for calculating the Total Cost of Ownership
TCO = I + O + M + D + P + R
I – Initial cost. Usually around 10% of TCO.
O – Operation. Cost of operation.
M – Maintenance. Cost of maintenance.
P – Production. Cost of production.
R – Remaining Value.
That’s the math behind TCO. So, how does this apply to cloud migration? Here’s a quick example extracted from Amazon’s pricing calculator for Amazon Athena.
The estimated cost of running Amazon Athena is $1,500 per day, with 10 queries and 1TB of scanned data per query. That’s quite of sum, but this, in no way, simulates the way TOC works in a real-life scenario.
Compliance and security evaluation/assessment
In order to unload software and infrastructure to the public cloud, the company must meet several regulatory requirements. The most common are GDPR, HITRUST, PCI-DSS, and HIPAA. Depending on the cloud service you choose, you may need to obtain other regulatory certificates. For additional information on compliance pre-requisites, you may want to consult your cloud supplier’s manual.
On the topic of security requirements for cloud migration, please consult the checklist below.
1) Bandwidth planning. The new model and improved data flow will, more than likely, draw additional bandwidth. Plan in advance to prevent any hiccups along the way.
2) Solving remaining compliance issues.
3) Data Loss contingency plan.
4) Create an actionable LMF (Lifecycle Management Framework).
5) Additional security padding (IDS/IPS, web-app firewall, cloud access security broker, etc.)
Courtesy of Amazon AWS
Technical evaluation
This phase involves apps and data overview and classification. During the technical assessment, apps will be prioritized (e.g. legacy, business purpose, and user case).
Up next, we have data classification, a sub-phase in which we ascertain aspects like data sensitivity, damage sustained during transit, intellectual property, and shareholder info. The very next step is requirement & compliance eval, where the tech team determines if the company fulfills all cloud migration requirements. Finally, a preliminary decision is pushed to management.
Gathering your toolkit
The name says it all – based on the results of the tech and financial evaluations, the sysadmin will gather the tools necessary to make the cloud transition. Note to self: some tools can be reused, while others have to be constructed from scratch.
Migrate, create, and measure
A top-level evaluation whose purpose is to determine the feasibility of the entire endeavor.
B) Proof-of-concept
During this phase, a pilot program is constructed. Basically, this is a getting-your-hands-dirty situation, because this is your first encounter with the cloud. Many vendors offer extended trials for their products. And yes, that’s good news for your sysadmins since they’ll be able to perform several performance tests on the future cloud infrastructure.
C) Migrating the data
The next step involves moving the data from your on-premises storage devices to the cloud service of choice (i.e. fileservers, commercial RDBMS, and MySQL)
D) Migrating your applications
Define and implement your migration strategies. There are different types of cloud migration , but the most common are forklift and hybrid migrations. Now, in forklift migration, all apps and their dependencies are moved to the cloud in a single and swift move.
This type of strategy is recommended when you deal with tight-knit applications (i.e. interdependent apps that can’t be separate) or self-contained apps. Now, in hybrid migration, all the apps and their dependencies are moved to the cloud one at a time.
This strategy is usually employed when there’s an increased risk of data loss during transition. Furthermore, since apps are moved one by one, the sysadmin can also use this time to optimize apps before they are being moved to the cloud. While forklift strategies are recommended for interdependent applications, hybrid strategies are best used for loose apps, with little dependencies.
The 5 R’s of cloud migration
Forklifting and hybridization are then only cloud migrations strategies available. In practice, the process itself is governed by the so-called 5R migration flow. The 5 R’s of cloud migration are: Rehost, Refactor, Revise, Rebuild, and Replace. Let’s check out these steps to cloud migration.
Rehost – a reenactment of the app architecture on the cloud infrastructure of choice. Usually applies when going with an Infrastructure-as-a-Service provider (IaaS). I’ll get to that in a moment.
Refactor – this cloud migration strategy applies to companies willing to go along with a PaaS provider (Platform-as-a-Service) instead of IaaS. It involves recycling existing frameworks and code.
Revise – this strategy has more to do with code and frameworks than with service providers. It involves expanding and/or rewriting the code base in order to deploy the apps to the cloud.
Rebuild – it’s exactly what it sounds like: rebuilding everything from scratch. Basically, this strategy means writing new code and creating a framework so that the apps can support the new cloud platform. Works best with the PaaS cloud.
Replace – you can also choose to wipe the slate clean and start anew. In the context of cloud migration, this means ditching legacy or outdated applications and utilizing the apps/tools provided by your SaaS vendors.
E) Stretching your legs and optimization
At this point, you’re knees deep in the cloud. Congrats would be in order, but there’s still a lot more to be done. First of all, you should find a way to leverage all the services offered by the cloud. Depending on your choice –more about that one in the upcoming section – these services will help you optimize your apps and flows. You should also look towards a more centralized view of the cloud resources and your assets.
Concerning optimization, there’s such a thing called an optimization loop – a framework that defines the goals, challenges, and solutions of the post-migration optimization process. Generally, each team in charge of migration creates its own loop. For example purposes only, here’s how the optimization loop looks like for the G-Cloud.
Courtesy of Google
Cloud-idiosyncratic security concerns
Cloud migration comes with a set of unique cybersecurity challenges. Up next, I will try to highlight the most important issues and, of course, some workarounds.
1. End-user has less control over the cloud-hosted apps.
One of the least enjoyable facts about cloud migration is the lack of autonomy when it comes to the end-user. It may seem like a minor inconvenience, but it can very well turn into a liability should the cloud provider’s server comes under attack. There’s no working your way around this. Well, not directly, at any rate. Before choosing a cloud provider, be sure to review their security certificates and, if the case demands it, make some provisions of your own. You should also consider a hybrid DLP solution – cloud + physical backups.
2. Fake VM instances
It’s very easy to create and configure virtual machines or containers in a cloud environment – great for UX, but not that awesome when it comes to internal security. Since anyone with the right credentials can access and commit modifications to the apps, data, VMs, and containers located in the environment, it’s quite easy to imagine what would happen if a threat actor would get his hands on your credentials.
Pseudo-VMs can immediately be spawned within the environment and utilized to exfiltrate company-critical information. Workaround includes changing username – passwords pairs, periodical cybersecurity training, and privilege-based access (i.e. only users with admin rights should be allowed to create or commit modifications to cloud resources and apps.)
3. API susceptibilities
An API (Application Programming Interface) is a type of computing interface that intermediates the interactions between two or more pieces of software. The major advantage of utilizing APIs is that they don’t have to know how apps are implemented; this saves developers a lot of time and money.
However, unsecured APIs can become a point of access for malicious actors. Now, there are plenty of tools out there that can help you see the URL associated with each API call, as well as the parameters the API expects. Those tools can also be used by hackers looking for a way inside your databases.
4. Insider threat
Whether you’re in the cloud or still relying on internal gear, there’s really no way to quell down the insider threat. The wrong person with the right credentials can bring the entire organization on its knees in a matter of seconds. My advice: An A-prime access governance solution and treating your employees right.
5. What is deleted may never be removed.
Secure deletion of data is one of the challenges of cloud data storage and management. Now, deleting local data (e.g. uninstalling apps on a computer and wiping temp data) is easy. If the uninstallation wizard doesn’t get the job done, you can use file shredder in order to delete the remaining data. That may become a problem in cloud computing since the data dependencies of an app are hosted on more than one center.
6. Cloud lock-ins
In some circumstances, changing the cloud provider may be the right move for your company, especially if your current CP doesn’t is lackadaisical when it comes to cybersecurity.
However, changing the cloud provider is not as easy as switching from Netflix to HBO Go. In fact, in some cases, it may be next to impossible to migrate your data to another cloud due to the fact that cloud service providers use non-compatible tools, unique API, and non-standard data formats.
Heimdal® Network DNS Security
- No need to deploy it on your endpoints;
- Protects any entry point into the organization, including BYODs;
- Stops even hidden threats using AI and your network traffic log;
- Complete DNS, HTTP and HTTPs protection, HIPS and HIDS;
Cloud migration tools
Naturally, one needs the right tools in order for the job. So, what are the best cloud migration money can or can’t buy? Here’s a list of some of my favorite migration tools. Sorry, no raindrops, kettles, or kittens this time. Check out these cloud migration services.
1. AWS Server Migration Service
Amazon’s SMS is a web-based service that allows you to move thousands of workloads to the cloud. The Server Migration Service has some very cool features like advanced scheduling, tracking incremental replications of the live server volumes, fully customizable controls, low bandwidth consumption, and minimal downtime. On top of that, it’s free to use.
2. AWS Database Migration Service
The Database Migration Service is a great way to move large databases to the AWS. It’s secure, lightweight, and capable of consolidating databases up to one petabyte. Other nifty features include low cost (starts at $3 per month), task automation, and database multi-format support (i.e. compatible with both homogenous and heterogenous databases).
3. TSO Logic
TSO’s data-driven Logic tool can quickly generate cloud computing analytics and app recommendations. Not a cloud migration tool, per se, but quite useful in making cloud estimates (e.g. how optimized an app should be, are you running the right software, should you upscale or downscale your architecture, etc.).
4. AWS Migration Hub
The AWS Migration Hub is an all-in-one cloud migrations solution that can help you eyeball the progress of your app migration process across multiple clouds. Other noteworthy features include improved visibility, tracking for individual apps, migration & optimization metrics, and more.
5. AWS CART (Cloud Adoption Readiness Tool)
CART helps you measure the impact of cloud migration. The tool provides accurate metrics on business, people, applications, and customers. Some cool features you should look forward to cloud readiness heatmaps, monthly readiness reports, charts, and more.
AWS vs. Azure vs. Google Cloud
At the moment, the cloud migration market is divided among thee major players: Amazon’s AWS, Microsoft’s Azure, and Google’s Cloud. Below, you’ll find a table containing the features and services offered by the three contenders.
| Amazon AWS | Microsoft Azure | Google Cloud |
|---|---|---|
| • Virtual Server Instances • Elastic Beanstalk PaaS • Lambda Serverless Computing • ECS Docker Management • EKS Kubernetes Management • S3 Object Storage • Glacier Archive Storage • EFS File Storage • CloudFront Global Content Delivery • Redshift Managed Data Warehouse | • Virtual Machines • Cloud Services PaaS • Azure Functions Serverless Computing • Container Service Docker Management • Kubernetes Service • Black Blob Object Storage • Archive Storage • Azure Files • Delivery Network GCD • SQL Warehouse | • Virtual Machine Instances • App Engine PaaS • Cloud Functions Serverless Computing • Container Engine Docker Management • Kubernetes Engine • Cloud Storage • Cloudline Archive Storage • Avere/ZFS File Storage • Cloud CDN • Big Query |
Cloud delivery types
Throughout the article, I’ve mentioned stuff like IaaS, PaaS, and SaaS. These are called cloud delivery models, each having its own particular area of expertise. For instance, IaaS covers storage, virtualization, CDN, networking, and computing. On the other hand, PaaS will be of great help in the area of application platforming, database, development, and integration, while SaaS takes care of Business Management, security, and tools.
Pros and cons of cloud migration
By now, you’re probably wondering whether or not cloud migration is worth it. Well, as far as I’m concerned, it’s a must-have for a fast-evolving company. Cloud offers you speed, flexibility, increased storage capacity, and decreased maintenance costs. Cloud migration has, indeed, a lot of ups, but what of the downs? Check this out.
| Pros | Cons |
|---|---|
| Increased efficiency – outsourcing, minimal disruptions, improved client services Data centralization – view, review, and commit changes to data from all your cloud-connected devices Scalability – limited in the public cloud. Consider investing in a hybrid or private cloud. Improved Data Recovery– as compared to an on-premises solution. Collaboration – business collaboration is easier and more secure on the cloud Decreased data storage-associated costs. | Security concerns – CSPs employ the latest cybersecurity countermeasures to protect data, but security breaches can also happen in the cloud. Even worse is the fact that a public cloud, for instance, holds the data of hundreds of companies. Inflexibility – some data storage and formatting issues that may prove to be disadvantageous towards the client. Cost concerns – every cloud vendor has its own payment schema. Most operate a Pay-Per-Use pricing tiers, but not all. Carefully review the terms and conditions, especially under “Pricing” so as not to pay more than you're bargaining for. |
One last thing….
In cybersec, there’s a saying that we value above all other: “there’s no such thing as too much security”. To that end, I highly recommend adding an extra layer of security after making the transition to the cloud.
Heimdal™ Threat Prevention Network may be the ideal choice for your company’s cloud. Primarily a perimeter solution, Heimdal™ Threat Prevention Network offers full DNS protection, actively blocking every and all threat before they have a chance to reach your systems. Some features to look forwards to protection against known and unknown infections, passive and actives modes, full network logging, and MDM.
Conclusion
Cloud migration just makes sense. It’s financially sound, easier to manage, and, in the long run, it’s far cheaper than running physical equipment. Of course, this doesn’t mean that you should go on a rampage, throwing out all gear. As I mentioned, you should at least keep one on-premises server up and running for DLP purposes. Any questions about cloud migration? Head to the comments section and let me know.
Thanks for this amazing article. I generally read your articles with a lot of enthusiasm because of its content.