Skip to content

Securely Migrating to the Cloud

August 8, 2019

Cloud migration is an ongoing trend.

You've heard of the cloud and you're probably vaguely familiar with the concept of cloud storage. There are numerous benefits for moving to the cloud: scalability of infrastructure, cost reduction, increased automation, and much more. It’s estimated that by 2020, 83% of enterprise workloads will have moved into the cloud.

However, cloud migration can be a challenging process. A key issue is to maintain tight security both during the migration and in the post-migration environment. Ideally, once the migration is complete, the resulting cloud assets will have security that’s not only robust, but also highly automated.

In this article, we’ll discuss some important elements to consider before and during a migration, and several common problems to avoid, with an emphasis on security considerations.

Cloud migration: an overview

Cloud migration involves moving your data and applications from an on-premise environment over to a cloud service provider: one that offers a virtual pool of on-demand compute, storage, and network services at scale. It starts with understanding the benefits of the new system, analyzing the existing system, planning the migration, and finally, migrating.

For an organization with a large number of legacy applications, the decision to migrate can be difficult. Cloud migration can seem very intimidating, with many unknowns. But cloud computing is now a mature industry, and there are many tools available to help with the migration process.

When beginning a migration, the most important thing is go slowly. Thorough and careful planning will make implementation straightforward. Different organizations have taken different approaches for their migrations. Effective strategies tend to follow some variation of the sequence mentioned above. Let's break the process down step-by-step.

1. Assess opportunities

The migration begins with documenting the business case for the migration. Why is your organization doing this migration? What specific benefits do you expect to achieve? Later parts of the process will depend on the answers to these questions.

Next, assemble (or create) comprehensive architecture documents for the existing environment. You need a complete list of all the assets (applications and data) that currently exist. Later, you will also need to know how they interact and how they depend on one another.

For each application, decide if it will be migrated. Consider the scope and constraints of the migration: if this application moves to the cloud, what data stores will need to go with it? What other resources will it require? How much technical debt does it contain? Will the migration provide an opportunity to reduce or eliminate this debt?

At the end of Stage 1, you should have a final list of the assets which will be migrated.

2. Determine scope of change

In Stage 2, you will iterate through the list of applications from Stage 1, and assess the desired post-migration design of each.

For each application, you should decide upon the appropriate scope of change for this application — the amount of architectural refactoring or redesign that occurs during the migration.

There are four possible choices:

  • Rehost: Move an application to the cloud with no architectural changes. This is the fastest and simplest approach.
  • Replatform: Move an application with only a few changes for optimal cloud usage. For example, to eliminate the management of database instances, the application might use a cloud relational database service. Instead of needing a DNS server, it might use a cloud DNS service. And so on.
  • Repurchase: Replace a purchased/licensed application with one that is designed for the cloud.
  • Redesign: Modify an application to use service-oriented architectures. This is obviously the slowest, most invasive, and most expensive strategy, but it can produce many long-term benefits.

At the end of Stage 2, each application will have a complete post-migration design.

3. Map dependencies and plan

Very few organizations attempt to move everything to the cloud at once. It is far more prudent to start by migrating only a few applications — perhaps only one — to minimize the impact of the inevitable challenges that will occur. Then, once this process has been completed successfully, larger groups of applications can be migrated more smoothly.

Therefore, in this phase, the primary goals are:

  • To map out and understand the dependencies among the applications that will migrate, so that…
  • The stages of the migration can be planned, including the order in which assets will be migrated, how progress will be tracked and managed, and how security will be maintained during and after the migration.

Migration order is not driven solely by technical dependencies. Other factors include business considerations and operational issues. For example, a particular application might be responsible for a large portion of current revenue. Often, it makes sense to migrate other applications first, so that unforeseen problems can be solved with applications that are not mission-critical.

On the other hand, there might be reasons to migrate a particular application sooner. Perhaps it is experiencing a problem that has been intractable on-premise, but will be possible to solve once the application is in-cloud. There are often situations where customer applications or APIs are plagued by hostile bots that traditional on-premise security solutions cannot detect.

That's why investing in a cloud migration software is a popular option for companies looking to securely migrate to the cloud. These programs allow you to sync applications with cloud storage systems, integrate with backup software to keep files safe during migration, and provide features for data encryption in one singular location.See the Easiest-to-Use Cloud Migration Software →

What is cloud security?

During Stage 3, security considerations should play a large role in your planning. Let’s talk about them now.

Cloud security is poles apart from traditional security models. Thus, the tool sets and processes used for managing traditional on-premise environments are not wholly applicable to the cloud.

On-premise security is usually treated as a product, rather than as a process; the security team puts up a guardrail around the entire infrastructure, to protect the workloads (and the infrastructure itself) from various threats. There are a number of weaknesses here: the products do not scale, they lack features, and they do not adapt well to constantly evolving threat environments.

On the other hand, cloud security is more focused on a service-oriented architecture that includes security in all stages — from design to development to the operations process. It allows companies to leverage a SaaS approach, where the burden of scrubbing the malicious traffic can be moved to a cloud security provider.

Also, since the cloud is different than a traditional on-premise environment, new tool sets are required: tools which can ingest the various event points, draw correlations, and raise the necessary threat notifications. Then, automated remediation for the triggered incidents can be performed.

Best practices for cloud security 

Whether or not your organization has adopted DevSecOps, you should certainly embrace one of its core concepts and “bake security into your cloud migration and infrastructure. Your migration plan should have security controls built into it in order to avoid any unforeseen risks or unwelcome events. Here are some security best practices to put into place.

Plan the governance

The migration plan should include the governance plan for the cloud environment and the entire migration process. It is essential to lay out an entire data migration plan that includes the starting point, passage points, and endpoint for the data. For each point, the migration team should have clear access controls, ensuring necessary team members have visibility.

Before the migration begins, appropriate guardrails should be created (and of course, subsequently maintained and monitored) around the new cloud resources and the assets they will soon contain. During the migration, only the necessary people should have access to the cloud environment.

After the migration, the list of necessary people should be reevaluated, and permissions should be updated. Often, some or even all of the migration team will no longer need the same permissions as before, and thus they should not retain them.

Identify and eliminate control gaps

When it comes to security, the mid-migration period is sometimes overlooked. Consider the passage points through which the data will travel: will the data stores be fully protected the entire time, to the most stringent standards to which your organization is liable?

Most organizations today are subject to one or more sets of data privacy laws, along with some compliance standards, and possibly additional industry-specific regulations as well. During the migration, will the data be continuously protected in accordance with the applicable standards?

Select tools and services according to post-migration needs

Some cloud platforms provide security tools and services for their customers. These can be useful in some ways, but they are limited in scope. On their own, they do not provide adequate security. 

It might seem convenient to rely on built-in tools “just for the migration,” with the intent of adopting a more comprehensive toolset later. However, this approach is flawed. First, it leaves significant gaps in your security posture during the migration.

Second, those gaps sometimes last for much longer than intended. Like all other complicated endeavors, cloud migrations often include unexpected problems and delays. And even when a migration is completed, there will always be other issues to work on — issues that seem more urgent than spending time and resources on changing a security posture which has not (yet) resulted in any problems.

It’s far better to assess your post-migration security needs now, during the planning process, so that you can adopt the necessary tools and services during the migration. This ensures robust security during and after the migration, and ultimately, is more cost-effective.

Keeping track of vendor contracts, employee permissions, and compliance is tricky. Manage all of post-migration needs with G2 Track.

Manage my software compliance →

Enable immediately

It is often said that security monitoring should be enabled after migration, but it should really be the other way around.

Security for your infrastructure, applications, and other components should be enabled from day one of the migration process to ensure that there is no slippage before the actual go-live of the production environment.

As discussed above, this requires choosing the right tools and services, as well as a security team that is continuously monitoring threats and updating the security alerts and landscape as the migration process continues. In fact, you should consider enabling it even sooner — during the pre-migration planning.

Once you have decided to adopt a platform like this, it usually makes sense to start using it as soon as possible, especially for the applications that will not be significantly redesigned during the migration. The security platform can be fine-tuned for these applications now, rather than later. This eliminates the post-migration training period which otherwise would occur, and therefore accelerates the overall timeline.

When Stage 3 is complete, you should have a schedule which includes:

  • Every application and data store that will be migrated
  • The order in which each will be migrated
  • A timeline for each one
  • A list of required cloud resources, including security tools and services
  • And a schedule for resource deployment

4. Create infrastructure

Before anything can migrate, it needs to have a place to which it will go. Cloud services and necessary resources (e.g. storage) must be deployed, secured, and verified before anything can be moved to the cloud.

If Stage 3 was done correctly, then you already have a complete map of what infrastructure needs to be created, and the order in which to create everything. Stage 4 is then merely an implementation of that plan.

5. Migrate and validate

This stage is where the actual migration occurs. Again, this is primarily an implementation of the plan created in Stage 3.

In a typical migration, you will probably go through this phase several times. It’s common to migrate one application (or one group of applications) at a time. Each should be migrated, validated, and operational before proceeding to the next.

The validation process will usually vary across applications. Those which are merely being rehosted require less validation and testing than those which were significantly redesigned or refactored for the cloud.

An important part of the validation process is verifying that your migrated applications are properly secured. An effective cloud security solution adapts itself to each API and application that it’s protecting; this requires the solution to train itself for each one, which takes some time. Plan ahead and you won't run into easily preventable problems during this stage.

Demystifying the cloud migration process

When migrating to a specific public cloud platform, it’s also helpful to consider the platform-specific migration tools that each one provides. The cloud migration journey can be rewarding if the whole process — from planning to execution — is planned thoroughly, with adequate guardrails put around the plan to avoid any slippage from the desired state.

Interested in learning more about the cloud? Check out our category on cloud management platforms and how they help visualize multiple clouds in a single vision.

Never miss a post.

Subscribe to keep your fingers on the tech pulse.

By submitting this form, you are agreeing to receive marketing communications from G2.