During a cloud migration there are a lot of things that can go wrong, same as with any data center migration. Cloud migrations are a very complex process. Just a few of the most important things to keep in mind are app dependencies, security policy changes, network changes, and transitioning from capex to opex.
A process which, on paper, should be as simple as “plop all our workloads on their servers, not ours,” is typically anything but simple. This article will go over each of the most common errors with any data center migration to the cloud, as well as how to avoid them.
The 7 Most Common Cloud Migration Errors
1. Unnecessary Cloud Usage
Don’t use the cloud when it isn’t right for your business needs. The cloud has some amazing benefits, but it is not right for every situation. A data center migration to the cloud can offer significant cost savings due to a lack of infrastructure costs associated with physical servers, but it is unsuited to some situations.
A data center migration to a public cloud is a bad idea when:
- The Flexibility of the cloud isn’t necessary
- An enterprise with consistent workloads won’t get the benefits of the cloud’s flexibility. Additionally, if an enterprise’s workloads change consistently, then their infrastructure can be set up to handle the changes like the cloud would. In these cases, the cloud can be used for testing to understand the computing needs of a new operation.
- Once the enterprise is familiar with the needed infrastructure, it can transition to its own custom cloud that costs less while still being sufficiently suited to handle shifting workloads without tons of redundant servers.
- Your data center is being used to house highly sensitive, highly valuable data
- When housing data in the cloud, the control of its security is no longer in your hands. A private cloud or in house infrastructure will likely be more appropriate in that scenario.
A more appropriate time for a data center cloud migration is where the bulk of an an enterprise’s data is not sensitive or high value data. More appropriate situations for cloud migrations include when the goals are primarily revolving lower tier use cases like dev ops, data backup, archives, or disaster recovery provisions. Essentially any data that doesn’t need to be readily at hand at all times, that isn’t terribly important but still needs to be maintained and used semi-frequently.
2. Choosing the Wrong Type of Cloud Provisions
Choosing the wrong type of provision can be severely detrimental. While many times the cloud is referred to as one all-encompassing entity, the reality is that it’s a service provided in many different formats and from more than a few unique vendors. There are a few different types of public cloud storage, each with various pros and cons.
Choosing block storage for junk data when perhaps cold archiving was more appropriate can have hefty unnecessary costs. Here is a quick overview of the different types of cloud provisions and what each type is used for:
- Archiving: Very cheap, usually using tape storage or idled disk storage; takes a long time to access, so mostly should only be used for data that will almost surely not be needed in any fashion for a long time.
- Cool/Cold Storage: Low cost, but data stored here is only marginally easier to access than archived data; an economical option to house massive amounts of archival data but still be able to access it in a reasonable amount of time.
- Active storage, also known as nearline, Active Archived, or chilled storage: Disk or high performance tape libraries; analytics data or data for semi-frequent discovery searches would be a sensible fit for this type of storage
- Secondary Storage: Generally comprised of lower end SATA disk storage; good for backups of important data or snapshots
- Primary Storage: Flash memory and high-end disk storage; The most important data that needs to be accessed readily is most appropriate for this type of storage.
Imagine worst case scenario how quickly you would need to access the data, and then choose the type of storage provision that meets that time frame closest.
Choosing a Cloud provision that’s too far away can cause latency issues down the line. The cloud is a wonderful technology seemingly built from fairy dust and magic. However, it also still follows the laws of physics, and cloud computing resources are provided by physical servers in data centers.
The further away the cloud is hosted from your location, the higher the latency between your servers and their servers will be. For some enterprises a slight difference in latency is quite acceptable, but for others, it’s a dealbreaker.
Find out how far away each cloud’s base is located from you before committing to a vendor.
4. Unsecured data
As responsibility is shifted from the enterprise to the cloud, the path to data security can become cloudy. Unfortunately, decision makers don’t have the luxury of being unsure on data security.
Despite the shift in secure responsibilities to the cloud, the mandatory security requirements of the enterprise remain after a cloud migration implementation.
Before, the enterprise was expected to proactively defend against data security threats constantly on site. This required a skilled technical crew to uphold secure infrastructure. Now, the cloud provider will do much of this work.
Even though cloud vendors have bolstered data security in recent times, relying on the cloud provider as the sole security measure for your data is a data breach scandal waiting to happen.
Finding a solid service level agreement, monitoring that the cloud provider upholds it, encrypting data to and from the cloud, and establishing rigid access protocols and credentials will all be newly crucial tasks to maintain.
Additionally, user authorization and access, configurations for networks and systems, event recording, and network traffic should all be reevaluated as they apply to this shift to ensure that there are no data security issues.
5. Poor network reliability
While cloud vendor network reliability is generally consistent, many enterprise’s networks are not. Reliable network connectivity is vital for any enterprise relying on the cloud, as cloud access is contingent on a network connection.
Invest in a solid network and network provider if your company plans a data center migration to the cloud, and have your network audited by a third party or a sufficient in house expert. Network issues caused by improper VPN configs and routing issues are commonplace.
Moving an app to a new location when it relies on components in the old location can be disastrous.
As a result, app dependency mapping is widely regarded as vital to any IT move, and a cloud migration implementation is no exception.
Mapping these out in the past was tedious with traditional methods like domain specific discovery tools and spreadsheets.
As data centers grow and virtualize, these methods are no longer viable. Application dependency mapping tools are now an industry standard for any cloud migration implementation, as well as everyday usage. These tools automatically discover and “map” the relationships between apps and components.
These maps are imported into the configuration management database, or CMDB for short.
The CMDB helps in a few ways:
- Proactively understand the future effects of any potential changes
- Reduce downtime with better environment stability
- Effectively allocate resources by priority and value to the business
However, there are numerous potential opportunities for failure.
This strategy places a heavy reliance on the CMDB as the sole eyes of the operation. The present risk of that fact becomes readily apparent when you realize that the vast majority of CMDB initiatives fail.
These failures are partially a result of insufficient discovery and inventory tool capabilities. With improper tools, redundant or missing data is a likely possibility.
The majority of these issues can be avoided by choosing an up to date tool with a track record of consistency. Solarwind’s tool, as well as FireScope and Retrace are three examples of such tools.
The rest of the failures are largely due to human error. Disregarding synchronization between environment changes and the CMDB can lead to an out of date map. Being diligent to maintain a CMDB that accurately reflects change records will ensure a reliable tool with a host of benefits, including a more seamless data center migration to the cloud.
7. Customization Problems
Too Much Customization
Extensively customizing an Infrastructure-as-a-Service deployment can provide benefits, yes, but it can also make any future cloud migration implementation a nightmare.
The ability to template the environment and bootstrap migrations down the line is optimal. Typically the project takes on this shape when it’s spearheaded by a single department that creates highly specific policies, processes, and configurations within the deployment that aren’t largely relevant to the enterprise as a whole.
Not Enough Customization
Without tailoring a cloud implementation to fit the unique benefits of the cloud, those benefits are wasted.
A typical scenario with cloud implementations is the “forklift” maneuver. Many IT infrastructures form with an incomplete vision early on. From there, the infrastructure will evolve reactively to external forces.
The end result is an IT infrastructure that is not entirely optimized to fit the needs of the business. To plug and play an IT infrastructure like that in your cloud migration implementation leaves a lot of potential on the table.
If there is a plan to make rapid changes once the transition is complete, that’s one thing, but more often than not the infrastructure gets stuck in that format and the cloud migration never brings the benefits it was meant to.
Putting it all together
The cloud is no longer a novel service, but the impulsivity and excitement remain. Before jumping into bed with the cloud, make sure to go through the following steps:
1. Decide if the cloud is appropriate for your business
2. Determine which cloud provision fits your unique scenario most appropriately.
3. Evaluate your latency needs and how each cloud provider’s distance from you might affect them
4. Proactively establish new security policies and protocols to avoid any data leaks in this vulnerable transition.
5.Assess network reliability and bolster any weak points that may cause cloud access issues in the future.
6. Analyze dependencies and maintain an effective dependency map with carefully chosen tools
7. Customize the cloud provision to suit your business as a whole, and provide oversight to the parties spearheading the customization
What To Do With Leftover IT Equipment?
This hardware is typically an afterthought, and if it’s thought of at all, it’s likely given to a recycler for a hefty bill.
Exit Technologies provides the same on-site pickup, data destruction, and R2 certified recycling services as any IT recycler. The difference is, we operate under a “pay for product” model instead of a “charge for service” model.
This means that we’ll not only provide you the service you need to remove excess hardware in an environmentally secure manner, but we’ll also compensate you for the value of the data center equipment.
Visit our IT asset recovery page to find out how you could be compensated and see how our process works.