Three Phase Approach for Cloud Migration to Amazon Web Services (AWS)

Companies of all sizes are reinventing themselves on Amazon Web Services (AWS) every day. They are evolving their businesses, their processes, and their technologies to maintain a competitive advantage and to support changing business objectives. Teams are being retrained to adapt to changing roles in IT organizations; internal processes are being modified to enable lean, agile methodologies to thrive; and tools and technologies are being updated to enable innovation, modernization, and transformation.

Three Phase Approach for Cloud Migration to Amazon Web Services (AWS)
Three Phase Approach for Cloud Migration to Amazon Web Services (AWS)

AWS Migration Competency Partner, Rackspace accelerates the value of the cloud during every phase of digital transformation. By managing apps, data, and security, they help customers get to the cloud, innovate with new technologies and maximize their IT investments.

This whitepaper covers some of the challenges of application migration seen by those who have adopted the journey, and highlights best practices including:

  • The common challenges faced by business, both technical and non-technical
  • The 5Rs common approaches to migrate applications to the cloud
  • How to maximize ROI for your organization through a phased approach

Content Summary

Introduction
Migration considerations / Familiar challenges
Common approach
The 5 Rs
A phrased approach
The transition phase
AWS services
Supporting services
The optimize phase
Base services
Supporting services
The transform phase
Design Principles
Base services
Supporting services
Summary

Introduction

Companies of all sizes are reinventing themselves on Amazon Web Services (AWS) every day. They are evolving their businesses, their processes, and their technologies to maintain a competitive advantage and to support changing business objectives. Teams are being retrained to adapt to changing roles in IT organizations; internal processes are being modified to enable lean, agile methodologies to thrive; and tools and technologies are being updated to enable innovation and modernization.

AWS provides a compelling environment for modern businesses to rapidly restructure, retool, and enhance existing practices and technologies for the cloud. This whitepaper covers some of the challenges of application migration seen by those who have made the journey and highlights best practices we’ve discovered and implemented at Rackspace. Specifically, this whitepaper will focus on the technical aspects of migrating applications to AWS and the associated approaches we’ve established for applying them at maximum effect. Other important topics, including business process, compliance, and regulatory requirements, are not included in the scope of this discussion.

Migration considerations / Familiar challenges

Many migration efforts start by facing a common set of challenges, both technical and non-technical. Technological hurdles, while complex and often difficult or time-consuming, can almost always be overcome. Challenges related to people or processes, however, can be the largest, most formidable obstacles faced during a migration. These types of challenges, having very little to do with the actual applications and workloads being migrated, or the tools and technologies involved can cause migrations to fail before they even begin.

Challenges related to people, process or tool.
Challenges related to people, process or tools.

Some of the familiar challenges that prevent a migration effort from starting include:

Migration inexperience

Kicking off a migration effort with little or no previous experience is like setting off on a road trip without ever having seen or driven a car. All the planning and preparation in the world won’t help you out if you don’t first know how to start the car. Having a team with migration experience, cloud or not is necessary to ensure that the first steps on your journey to AWS are in the right direction.

Lack of AWS architecture knowledge

Knowing how to start a car and drive it is great, but if you don’t know where you’re going, or are unable to read a map, your journey will be filled with wrong turns and missed opportunities. If your team doesn’t have experience with AWS, your ability to map system requirements to AWS services and features and to identify gaps between those requirements and the capabilities provided by AWS, will be severely limited. Having a team with AWS experience means you’ll be able to hit the correct waypoints while in route to your destination.

Poor task prioritization

In the absence of organizational consensus and cloud computing champions, migration efforts can quickly devolve into second-class projects with no allocated time or resources for completion. Tasks associated with migration planning and execution can be categorized as nice-to-haves in the grand scheme, when they are must-haves for getting a migration off the ground.

Heavy workloads

Migrations take time away from other important work and can often be viewed as distracting from the normal day-to-day operation of a business or organization. Prioritization alone is insufficient when attempting to complete migration tasks. Dedicated resources, whether full-time or part-time, must be allocated for migration efforts to ensure forward progress. In the absence of sufficient resources, migration efforts are sure to stall.

Fear, uncertainty, and doubt (FUD)

Truth be told, there remain naysayers who believe the cloud is just a passing fad—that there’s no security in the cloud. Education and training play important roles in all migration efforts. Establishing champions within companies and organizations is vital for the success of any migration effort.

Solving all these challenges paves the way for both current and future migrations. The time to start is before the effort begins.

Common approach

Every organization approaches migrations from a slightly different perspective. That perspective is unique to the organization and influenced by the organization’s resources, priorities, and objectives. The end goal is the same; to successfully migrate one or more applications to AWS. The processes, tools, and methodologies used to get there, however, can vary greatly. An experienced migration team may take a more direct approach, driven by past successes and failures. Another team migrating the same application may take a less direct route; one that allows them to leverage their existing skillset and provides a learning platform for growth.

Regardless of experience, common to most approaches is a desire to both efficiently and expeditiously move to the cloud. At Rackspace, we’ve had the opportunity to work side-by-side with our customers as they’ve made their journey to the cloud. As part of this effort, we’ve identified several key techniques and behaviors that have led to successful migrations and have maximized the associated return on investment.

The 5 Rs

Successful migrations begin with an assessment of specific applications and workloads to determine migration feasibility. This assessment takes into consideration technical requirements, such as application dependencies and development environments. It also takes business requirements into consideration, including the time to market schedules, software licensing, staff training, and experience.

This assessment and accompanying categorization of applications is inspired by Gartner’s Five Ways to Migrate Applications to the Cloud, or the 5 Rs. The 5 Rs describe the five most common approaches to migrating (or not migrating) applications to the cloud.

Retire

Retired applications will be phased out, depreciated, or be classified as end-of-life during the migration or soon after. The effort required to migrate retired applications exceeds the benefit received from doing so.

Replace

Replaced applications are those whose functionality will be assumed by other applications or workloads, or will be offloaded to a SaaS provider with the same functionality.

Re-platform

Re-platformed applications will be moved directly to the cloud as-is, with as little modification as possible. Minimizing change allows these applications to be moved to the cloud as quickly as possible with the least amount of effort.

Re-architect

Re-architected applications integrate with additional cloud services and features during migration to increase the benefits of moving to the cloud. This integration requires more time and effort than re-platforming but yields additional benefit.

Refactor

Refactored applications take an all-in approach to cloud migration. These applications are rewritten from the ground up with specific cloud principles in mind. This approach helps maximize potential benefits seen in cloud-native applications and usually requires considerable time and effort to implement.

This assessment helps organizations determine which applications should not be migrated and which should. For those that should be migrated, the question then becomes, which migration approach should be taken?

A phrased approach

Most often, no single migration approach can be used for every application. One size does not fit all. Additionally, it’s rare for applications to migrate using just one approach. Typically, one or more approaches are used, making it a multi-step journey with intermediary destinations along the way, as shown below:

Transition:

  • Move quickly
  • Minimize change
  • Realize benefits!

Optimize:

  • Maintain momentum
  • Localize changes
  • Increase benefits

Transform:

  • Increase momentum
  • Maximize benefits
  • Go cloud-native!

This phased approach provides quick realization of AWS benefits and maximizes return on investment. It also gives organizations the opportunity to learn and grow application architectures as the journey progresses and teams gain experience.

Note: For a broader, more holistic approach to migration, the AWS Cloud Adoption Framework (AWS CAF) helps organizations understand how cloud adoption can transform the way they work. The AWS CAF identifies business and technical capabilities and perspectives plus it shows organizations where gaps exist, so they can maximize migration benefits and minimize costs. The AWS CAF is useful to review regardless of the complexity of migration and independent of organization size.

The transition phase

The Transition Phase (commonly known as a lift-and-shift or a forklift migration) is most often the quickest path to the cloud and the first stop on the journey to AWS. During the Transition Phase, the focus is on migrating applications and workloads to AWS as quickly as possible and with as few changes as possible. This accelerates the realization of cloud benefits as soon as possible. This first step to the cloud follows a least-effort and least-time approach and often results in substantial benefits such as:

The Transition Phase
The Transition Phase

Reduced Costs: AWS allows you to pay for resources as you use them, on-demand, without making a long-term commitment. By leveraging AWS global infrastructure and the economies of scale they provide, you can immediately benefit through cost reductions. AWS allows you to reduce costs immediately by allowing you to:

Eliminate the guesswork. Instead of pre-provisioning capacity for future needs, AWS allows you to provision resources when you need them. During the Transition Phase, you can right-size your infrastructure and immediately see the benefits in the form of cost savings.

Pay on demand. In the cloud, you can create a production-scale test environment on-demand, complete your testing, and then decommission the resources. Because you only pay for the test environment when it is running, you can simulate your live environment for a fraction of the cost of testing on-premises.

Commit and save. AWS allows you to purchase Reserved Instances, at a significant discount, for a term from one to three years.

Global Capability: Simply moving your application to AWS with little or no changes means you can immediately start to recognize the benefits of a global infrastructure. With multiple Availability Zones (AZs) in regions around the world, AWS allows you to very quickly move or replicate your application to one or more locations around the globe. You are no longer limited to a single location, office, or datacenter. You can easily and cost-effectively set up disaster recovery (DR) options to meet your specific DR requirements, whether they require you to move data across the continent or around the world. It’s even possible to get two geographically distant data centers for the same cost as one for the same workload. It’s a brave new world.

Increased Agility: AWS global infrastructure allows you to quickly innovate, experiment, and pivot if needed, all without having to wait for expensive hardware to start. Instead of waiting, developers can immediately build, test, and deploy new applications. Once in production, you can easily scale your application up to meet customer demand, and then elastically scale back down when demand subsides. Whether you need one virtual server or thousands, whether you need them for a few hours or 24/7, you still only pay for what you use.

Increased Security: Simply by moving your applications to AWS, you can immediately benefit from AWS architecture, which is built to meet the requirements of the most security-sensitive customers. AWS offers solutions that help customers meet different regulatory requirements. AWS provides a base security platform for you to leverage, including capabilities such as infrastructure security, data protection, identity and access control, and monitoring and logging. The shared responsibility model in AWS means AWS takes responsibility for security of the cloud (protecting the global infrastructure that runs all AWS services while customers are responsible for security in the cloud (protecting your data on AWS).

AWS services

AWS services used during the Transition Phase are typically those that require little or no change for your application to use. These services can be integrated into application architectures with minimal disruption.

The following are common services used during the Transition Phase:

Amazon Virtual Private Cloud (Amazon VPC) is a logically isolated, user-configurable, virtual networking environment that contains your AWS resources. You define the IP addresses that resources in your Amazon VPC will use, how subnets in your Amazon VPC will be structured, and how traffic will be routed into, out of, and within your Amazon VPC. You may choose to mirror your on-premises networking environment to your Amazon VPC to minimize changes during migration, or you may configure your Amazon VPC to extend your current environment to AWS.

Amazon Elastic Compute Cloud (Amazon EC2) instances are virtual servers in the cloud. Amazon EC2 instances come with varied CPU, memory, disk, and network capacity and are designed to meet a variety of use cases. This allows you to select Amazon EC2 instance types and sizes that match the operational requirements of your applications.

Amazon CloudFront is a growing, global, content delivery network, allowing you to securely push content and logic closer to your where customers need it. Amazon CloudFront is closely integrated with other AWS services and features, making it easy and seamless to use with your applications.

AWS Identity and Access Management (IAM) gives you the ability to securely manage users and groups and to administer access to AWS services and resources. You can create users, groups, and roles that define the type of access required for AWS services and for specific resources.

Amazon CloudWatch is designed to provide monitoring and logging services for AWS services and your applications. You can configure Amazon CloudWatch to send notifications when triggered by infrastructure and application metrics or events. It can then automatically add, remove, replace, or modify AWS resources on your behalf. Amazon CloudWatch gives you immediate, system-wide visibility into your AWS infrastructure and resources.

AWS Marketplace also provides access to familiar software and services provided by APN Partners.

Supporting services

In addition to AWS services that provide the core of your application’s infrastructure, other AWS services may be utilized during the Transition Phase, particularly those associated with data migration.

The following are supporting services used during the Transition Phase:

AWS Storage Gateway provides the ability for on-premises applications to seamlessly use AWS storage through familiar protocols such as NFS and iSCSI for file, volume, and tape access. AWS Storage Gateway can be used during migration to easily and transparently migrate data to AWS.

AWS Direct Connect allows you to build dedicated network connections between your on-premises network(s) and AWS. These connections provide consistent and reliable network connectivity and facilitate quick migration of applications and data.

AWS Snowball provides you with the ability to transfer substantial amounts of data to AWS, independent of your existing network connectivity to the cloud. AWS Snowball devices are shipped by AWS to your location where you populate them with data. Once populated, you simply ship the device back, and the data will be stored on AWS.

AWS Database Migration Service (AWS DMS) is designed to provide an easy and secure method to help you migrate databases to AWS and includes support for the most widely used commercial and open-source databases. AWS DMS can move your existing database to AWS and minimize cutover delays during the Transition Phase.

The optimize phase

The goal of the Transition Phase was to quickly and efficiently migrate applications to the cloud, and in doing so, minimize effort and change. The goal of the Optimize Phase is to take the first step towards true cloud integration. This is accomplished by enhancing applications to leverage AWS managed services. AWS managed services offload many of the burdens associated with running services in the cloud, such as application monitoring, performing backups, replacing failed resources, and patching software. AWS provides managed services for many common software components like databases, caches, queuing, and messaging services.

The Optimise Phase
The Optimise Phase

Leveraging services managed by AWS is critical to maximizing the benefits associated with migrating to the cloud. Doing so allows teams to focus efforts on building and iteratively improving upon applications and products, rather than on managing underlying infrastructure.

Benefits

Because this phase focuses on integrating AWS managed services, the benefits achieved are associated with the features and benefits of individual services used. Depending on the services used, these benefits include:

Improved Availability: AWS service availability can be selected based on the requirements you set. In the past, you had to plan, purchase, install, configure, and maintain. Now AWS manages automation as necessary to achieve high availability.

Improved Scalability: AWS services provide scalability options to fit the needs of your applications. This allows you to scale your application horizontally and/or vertically and rely on dependent AWS services to do the same.

Increased Agility: The use of AWS managed services allows you to quickly and easily experiment and innovate. You may decide you’d like to test your application using MariaDB or PostgresSQL. If so, Amazon Relational Database Service (Amazon RDS) allows you to easily launch temporary servers, and AWS Database Migration Service’s schema conversion feature could allow you to simply swap database technologies.

Improved Security: AWS managed services have security features built-in and leverage other AWS security services and features like AWS Identity and Access Management (IAM) and AWS Key Management Service (KMS). AWS even offers Distributed Denial of Service (DDoS) protection for its load balancers with AWS Shield.

Simplified Architectures: AWS managed services can reduce complexities in your architecture associated with managing and administering common infrastructure components like databases, caches, and networking.

Reduced Time-To-Market: The sum of all benefits realized after completing the Transition and Optimization Phases means your teams can focus on your product and not on infrastructure. As a result, product cycles are shortened, features released quicker, and customers are happier.

Base services

The following are the most common AWS managed services used during the Optimize Phase:

Amazon Relational Database Service (Amazon RDS) is a managed service designed to provide support for familiar database engines including MySQL, PostgreSQL, Oracle, SQL Server, and MariaDB. Amazon RDS handles common database tasks like patching, backups, and failure detection and recovery, allowing you to easily scale your database as application needs grow over time. Migrating your workloads to Amazon RDS can often be as simple as a database backup/restore and application configuration update.

Amazon ElastiCache is a managed service for in-memory data stores and caches such as Redis and Memcache. You can replace your existing self-managed in-memory data-store/cache with its protocol compatible Amazon ElastiCache equivalent, often by simply changing a connection string in your application.

Amazon Simple Email Service (Amazon SES) is a cloud-based email service, allowing you to include the functionality of a complete email service in your applications. You can use Amazon SES as an SMTP relay or use Amazon SES with an existing mail transfer agent with minimal changes to your application.

Amazon Elasticsearch Service (Amazon ES) is designed to eliminate the need for common administrative tasks associated with operating Elasticsearch clusters, including performing backups, monitoring, and patching software. Amazon Elasticsearch Service supports common Elasticsearch APIs, making it easy for you to easily replace your self-managed Elasticsearch cluster.

AWS Directory Service enables your directory-aware workloads to use managed Active Directory in the cloud. AWS Directory Service allows you to continue using familiar and standard Active Directory administration tools and take advantage of built-in Active Directory features while relying on AWS to manage monitoring, replication, backups, and failover for you. You can replace self-managed domain controllers running on Amazon EC2 with AWS Directory Service.

Other AWS services that are commonly used include Amazon Elastic Map Reduce (Amazon EMR), Amazon Simple Storage Service (Amazon S3), AWS Elastic Beanstalk, and others.

Supporting services

In addition to base services, supporting services, like the following, are often introduced during the Optimize Phase:

AWS Auto Scaling helps you maintain your fleet of Amazon EC2 instances by monitoring and maintaining a desired number of instances, growing or shrinking your fleet dynamically based on demand. AWS Auto Scaling is key to ensuring that you have enough instances to meet demand and maintain responsiveness.

Amazon Route 53 is a Domain Name System (DNS) designed for the cloud. You can easily use Amazon Route 53 with other AWS services like Amazon EC2, Elastic Load Balancing, and Amazon S3, plus add to external endpoints.

AWS Config is a service for security and governance of your AWS resources that allows you to track and analyze your AWS resource inventory and configuration history. You can configure AWS Config to notify you if there are changes to your AWS resources.

AWS Key Management Service (AWS KMS) securely protects and manages the encryption keys you use to encrypt your data using hardware security modules (HSMs).

Amazon Simple Notification Service (Amazon SNS) allows you to easily implement pub/sub messaging in the cloud. You can choose from a variety of protocols to deliver notifications to subscribers, including software-based endpoints, mobile devices, and other clients.

Other supporting services you might use during the Optimize Phase include Amazon API Gateway, Amazon Inspector, Amazon Simple Workflow Service (Amazon SWF), and AWS Trusted Advisor.

The transform phase

The goals of the Transition and Optimize Phases are to move quickly to the cloud and to maximize the use of AWS managed services, while minimizing effort and change. In this manner, you can quickly get to the cloud and begin realizing cloud benefits including cost, availability, and performance. In these phases, the architecture of your system remained relatively unchanged.

The Transform Phase
The Transform Phase

The goal of the Transform Phase is quite different, however. In the Transform Phase, applications and architectures are often changed to take full advantage of the cloud and maximize its benefits. In this phase, applications are changed to make them cloud-aware, and by doing so, they can achieve the highest level of benefits. Transformed applications can help reduce time to market, achieve cost savings, realize maximum availability, and establish agile methodologies. The goal is to integrate new services and features as they become available and to refactor applications around proven cloud design principles.

Design Principles

Some of the design principles that drive change during the Transform Phase include:

Stateless Applications are applications that maintain no knowledge of previous interactions and store no session information locally. Stateless applications enable horizontal scaling, as requests are able to be handled by any available resource. As new capacity is required to handle increasing demand, new stateless compute resources may be easily added. As demand ebbs, stateless resources may be drained and removed. State, in the form of session information or files, may be moved to other AWS manages services, such as Amazon DynamoDB or Amazon Elastic File System (Amazon EFS). The purpose of considering state in cloud native applications is to abstract compute and storage, allowing you to easily scale and recover from server failure without data loss.

Disposable Infrastructure is used in cloud-native applications instead of traditional fixed resources. Instead of provisioning resources weeks or months in advance, they are provisioned on demand. In the cloud, dynamic provisioning of resource requires new, modern techniques to be used to configure temporary resources. These techniques include the use of golden images, immutable systems, system bootstrapping, and infrastructure as code. They require changes in the way infrastructure is viewed and the processes used to manage and administer it in the cloud.

Loosely Coupled systems are designed in such a way to reduce dependencies between systems to isolate changes and failures and prevent catastrophic, cascading failures. Loosely coupled applications include well-defined interfaces between systems, utilize service discovery to locate dependent services, and provide for asynchronous operation. Applications and interfaces often need to be rewritten and retested during this phase. Once complete, loosely coupled applications are fault-tolerant and resilient to failure.

Infrastructure Automation is a requirement for highly available, elastic systems to operate in the cloud. The dynamic nature of these systems requires the tools and processes associated with their operation to be applied dynamically, as well as on-demand. Manual execution of processes, as might have been done in non-cloud environments when working with single servers, is no longer a viable alternative. Tools and processes, including continuous integration and continuous delivery pipelines (CI/CD), are required to achieve maximum agility and minimum time to market.

Caching is a mechanism to save previously calculated values or fetched data for future use, thus reducing the time and effort to retrieve the information again. Caching may be applied at multiple layers in a system, including at the application level and at the edges of the system. Application caching often utilizes in-memory data stores, such as those provided by Amazon ElastiCache, to ensure data can be quickly and efficiently retrieved from a central, managed location. Edge caching utilizes services like Amazon CloudFront, a content delivery network (CDN), to push data around the world, to locations closer to end-users.

Database choice is no longer a one-time, one-size-fits-all answer when building applications for the cloud. In cloud-native architectures, multiple databases are frequently used, depending on the needs of the application and use cases to be covered. Relational databases may be used where normalized data and strict ACID (atomicity, consistency, isolation, and durability) properties are required. NoSQL databases (such as Amazon DynamoDB) may be used in cases where additional schema flexibility is required and to achieve higher performance levels or horizontal scalability.

In addition to these techniques, other popular design principles are implemented during the Transform Phase, such as removing single points of failure in systems or utilizing microservices. Each of these techniques can further efforts to maximize benefits and become more cloud-native.

Base services

The following are AWS services that might be utilized in the Transform Phase:

AWS Lambda allows you to run code written in popular programming languages simply by uploading it and configuring triggers to execute it. You don’t have to provision servers or worry about when you need to scale or by how much. You can replace existing Amazon EC2-based services with custom AWS Lambda based services or implement cron-like functionality using entirely serverless infrastructure.

Amazon Elastic Container Service (Amazon ECS) is a managed container orchestration engine that allows you to manage clusters of any size and provides you with the ability to schedule and place containers for your application.

Amazon API Gateway is a managed service that allows you to create and maintain APIs at scale. You can use Amazon API Gateway as part of your cloud-native strategy in combination with other services such as AWS Lambda and Amazon DynamoDB to build out the serverless components of your architecture.

Amazon DynamoDB is a managed NoSQL database that supports both document and key-value store models and provides consistent, low latency access. You can use DynamoDB as part of a complete serverless strategy, or as a replacement for self-managed NoSQL engines.

Amazon Simple Queue Service (SQS) allows you to decouple and scale your applications independently of one another. You can use SQS with other AWS services like Amazon RDS, Amazon EC2, AWS Lambda, and Amazon S3 to build highly scalable and resilient distributed applications or use as a key component in your serverless strategy.

Other AWS services you might use include Amazon Simple Notification Service (SNS) and Amazon Kinesis.

Supporting services

In addition to these base services, supporting services like the following are often introduced during the Transform Phase:

AWS CloudFormation allows you templatize your AWS infrastructure and reliably deploy and update that infrastructure in the same or multiple AWS Regions. You can place your CloudFormation templates under revision control, effectively treating your infrastructure as code.

AWS Code-Deploy automates code deployments to Amazon EC2 instances and on-premises or other servers. You can use AWS CodeDeploy to help provide automation or build out your continuous integration (CI) and continuous delivery (CD) pipeline.

AWS CodePipeline is a CI/CD service that builds, tests, and deploys your code. You can configure AWS CodePipeline to automatically build, run tests, and deploy code each time there is a code change, or you may choose to customize triggers and actions.

AWS Cognito allows you to easily add user sign-up and sign-in to your mobile and web apps. You can authenticate users through social media providers like Facebook or Twitter, or you can authenticate using your own identity system.

AWS Step Functions allows you to coordinate and control the execution of distributed or serverless functionality associated with your application. You can use AWS Step Functions to process state-machine like workflows using Lambda functions or utilize Amazon EC2 instances or on-premises servers to execute application code.

Other supporting services you might use during the Transform Phase include AWS OpsWorks, AWS CodeCommit, AWS Mobile Analytics and Amazon Simple Workflow Service (Amazon SWF).

Summary

Migrating applications to AWS is often considered an evolutionary process. Like the evolution of an animal species, those who are strong and can adapt to the changing environment around them, can survive to live another day. Those that can’t adapt in the face of change and fail to adopt new tools and evolving technologies, will struggle to survive. Some applications will fail because they neglect to modernize and retool their processes, while some will fail due to insufficient resources.

The fittest, however, will survive. They recognize the benefits of AWS and will modernize their tools and processes to leverage the benefits of the cloud. Their agility will allow them to thrive in an ever-changing environment and adapt to live and excel in the future ecosystem. They will embrace change.

Businesses that doubt the future of cloud computing or delay migration, will quickly fall to the wayside and become observers, as their cloud-adopting competitor’s rocket ahead. Change is difficult, but a necessary part of the evolution to become a modern, cloud-native business.

At Rackspace, we work with companies large and small, from startup to enterprise, helping them transform critical business applications and migrate production workloads to AWS. Our world-renowned Fanatical Support for the AWS team continues Rackspace’s long history of providing customers with support for the platforms they require as their businesses evolve. Rackspace acts as your partner during your transformation to AWS, providing expert guidance, best practices, and ongoing support for your AWS infrastructure and applications along the way.

Partner with Rackspace to jump-start your evolution, accelerate growth, and maintain your competitive edge.

Source: AWS and rackspace