what everyone needs to know about migrating applications ... · this manager’s guide paper...

What everyone needs to know about Migrating Applications onto AWS

Cloudsoft Whitepaper v 1.1 March 2018

2

Migrating Applications onto AWS

© 2018 Cloudsoft Corporation.

1 Introduction........................................................................................................................................................ 1

1.1 Who should read this whitepaper ...................................................................................................................... 2

1.2 About Cloudsoft and the Author ........................................................................................................................ 2

2 Understanding the Six Rs of Application Migration to AWS .................................................................................. 4

2.1 Why some applications are not migrated to the cloud........................................................................................ 4

2.2 Deciding on a Migration Method ....................................................................................................................... 6

2.3 Important: Choosing the right Migration Partner ............................................................................................... 7

3 Migration method #1: Repurchasing (‘Drop and Shop’) ............................................................................................. 8

3.1 Drivers of Repurchasing ..................................................................................................................................... 8

3.2 Benefits of Repurchasing ................................................................................................................................... 9

3.3 Risks of Repurchasing ........................................................................................................................................ 9

3.4 How to Repurchase ......................................................................................................................................... 10

3.5 What you need to Repurchase ......................................................................................................................... 10

4 Migration method #2: Rehosting (‘Lift and Shift’) .................................................................................................... 11

4.1 Drivers for Rehosting ....................................................................................................................................... 11

4.2 Benefits of Rehosting ....................................................................................................................................... 12

4.3 Risks of Rehosting ............................................................................................................................................ 12

4.4 How to Rehost ................................................................................................................................................. 13

4.5 What you need to Rehost ................................................................................................................................ 14

5 Migration method #3: Replatforming (‘Lift and Shape’) ........................................................................................... 15

5.1 Drivers for Replatforming ................................................................................................................................ 15

5.2 Benefits of Replatforming ................................................................................................................................ 15

5.3 Risks of Replatforming ..................................................................................................................................... 16

5.4 How to Replatform .......................................................................................................................................... 16

5.5 What you need to Rehost ................................................................................................................................ 17

6 Migration method #4: Refactoring (“Cloud Native”) ................................................................................................ 18

6.1 Drivers for Refactoring ..................................................................................................................................... 18

6.2 Benefits of Refactoring .................................................................................................................................... 18

6.3 Risks of Refactoring ......................................................................................................................................... 18

6.4 How to Refactor .............................................................................................................................................. 19

7 Summary ................................................................................................................................................................ 20

1



1 Introduction According to leading industry analysts, by 2020 there will be more enterprise applications running in the public cloud than anywhere else. The current bellwether analysis says the top global 1000 companies have, on average, around 2000 applications. In that single segment it’s two million workloads. Consider that the current state of cloud is 15% of those workloads but, over the next three years, it will rise to 75%, that means 1.2million workloads will move to the cloud in the near future.

But why and how is this happening?

There are three drivers for public cloud today:

Increase top line revenue The imperative is to compete better in the marketplace by being more agile, characterized by experimentation, velocity and quality, and measured by an increase top line revenue.

Improve bottom line net income Eliminate unnecessary IT costs from the business and focus on core productivity to improve bottom line net income.

Compete on a level playing field Public clouds democratize the access to the latest technology, which was only previously available to big companies with big IT budgets. This means small-budget fast organizations can now compete on a level playing field, technologically, with big-budget slow organizations.

Given these drivers, business leaders seek to measure their success with public cloud adoption across four key vectors:

Given these drivers and benefits, it’s clear why organizations are adopting cloud at a rate where more than half of all workloads will be on the cloud by 2020, the next question is “How are organizations getting on the cloud?”

There are two routes to cloud:

1. Deploy net-new applications straight to the cloud, often referred to as a Cloud First strategy.

2



2. Migrate existing services, applications and workloads.

This paper has been written to help an organization’s management team see the complete picture of application migration to AWS, including definitions, risks, benefits with high-level how-to and what resource guides.

With this complete picture, the management team of any organization should be able to begin planning their migration strategy which will generally look something like this:

1. Research the topic (this paper and other resources and expert guidance). 2. Create the Business Plan. 3. Discover the Application Landscape. 4. Decide a Migration Method for each application. 5. Execute the Migrations to AWS 6. Transition to AWS 7. Retrospective – adapting and improving migrations through learning

1.1 Who should read this whitepaper Some say, “it takes a village to raise a child”: it takes a team to exploit the cloud. Migrations to the cloud involve multiple actors, therefore this paper has been written with the following three roles in mind to ensure the Why, What and How is explained.

Business Leaders What is the business case to migrate to clouds, what are the business outcomes?

Change/Program Managers What is the methodology to migrate, what is the cost, what skills are required and the impact/benefit to services?

Implementation Experts What tools, technologies and skills will be needed?

This paper explains the decision criteria involved in selecting Rehosting, Replatforming, Repurchasing or Refactoring when moving applications to the leading public cloud, Amazon Web Services (AWS).

Each method is detailed with notes on useful tools, process, and the skills required to execute the method. The paper finishes with recommendations on how to choose a partner to help with migrations.

> Contact Cloudsoft for help in producing your Cloud Migration Business Case and creating your Well Architected AWS Environment

1.2 About Cloudsoft and the Author Steve Chambers has built clouds, bought clouds and consumed clouds over the past decade. With this unique experience with companies that range from small startups to global organizations, he helps Cloudsoft help

3



customers win by exploiting the cloud. Steve helps the community by sharing his cloud experiences through papers like this and speaking events like Cloud Expo Europe and the Service Desk Institute.

Steve is currently the Chief Operating Office of Cloudsoft. Cloudsoft have built up years of experience working with applications and automation in the cloud and have specially designed services to Migrate, Run and Evolve applications on Amazon Web Services (AWS) through the Rx3 solution.

This delivers real business outcomes for our customers: reducing costs, increasing uptimes, improving performance and responsiveness, and continuously exploiting the pace of AWS innovation.

How did Cloudsoft get here? Over the last 9 years, Cloudsoft has delivered successful outcomes through software development and service delivery, both locally and internationally, for companies as large and diverse as BT, IBM and Giumarra (headquartered in California).

Having developed cloud capabilities, software, patterns, practices and people solving complex cloud problems with large organisations, Cloudsoft are now democratising access to these special skills by making our services available to a broader range of UK organisations.

Cloudsoft is headquartered in the UK and a privately held company. Cloudsoft has a highly talented and experienced team of engineers and business consultants led by seasoned executives backed by a world-class advisory board.

4



2 Understanding the Six Rs of Application Migration to AWS This Manager’s Guide paper focuses on the second route to public cloud: migrating applications to Amazon Web Services (AWS).

When an organization is considering migrating an existing application to AWS they have six options to choose from – known as The 6Rs – for each application. It is common for complex, multi-application migration programs to use a number of these methods at the same time: there is no one, size fits all approach.

2.1 Why some applications are not migrated to the cloud Two of 6Rs – Remain and Retire – are decisions to not migrate an application to the cloud. Why do organizations choose not to migrate to the cloud?

Why Retain? Existing, significant sunk cost for non-cloud which necessitates the business to sweat existing assets and practices.

Legacy OS and applications are not supported in the cloud

The business justification for migrating is insufficient

Why Retire? Applications found during a Discovery project are no longer required (sometimes the fact they are still running is a “surprise” to the organization, and just turning them off can yield significant savings).

5



Applications may be duplicated in the organization so some can be retired

There may already be a decommissioning or consolidation project in progress, and the application is that scope

The application might be redundant, such as an old cluster or DR setup

The remaining four choices for migration are selected according to a wide range of drivers in play in the organization at the time that migrations are being considered. These drivers are usually uncovered in the Business Case process and provided as inputs to the migration strategy in the form of compelling events, pain points, application availability, skills available to do the migration, and what the future state of the application needs to be post-migration.

Compelling Event or Pain Point?

If the organization has a compelling event to evacuate a hosting environment, then a fast-paced Rehosting method can be the only option.

Is the application available in a Marketplace?

If an application can be Repurchased, then it can be a short-cut to cloud. But if the application is not on AWS Marketplace, then this path may not be possible.

Do we have the Skills, can we afford a Partner?

If the organization doesn’t have the skills to Replatform or Refactor, and they can’t afford to partner, then their options are limited to Rehost and Repurchase.

What is the application’s desired Future State?

If the plan is to evolve the application over several years, then Refactor might be the best path. While this is often the initially slowest method, it ultimately delivers the greatest agility

and ability to exploit cloud innovation, but it requires deep skills.

6



2.2 Deciding on a Migration Method The four migration methods are best understood on a spectrum from left-to-right, ordered by the effort, cost and complexity of achieving the migration. It is also true that this left-to-right arrangement also implies, at a high-level at least, the complexity and uniqueness of the application to the organizations.

There are some prerequisites to be covered before deciding on Migration Method.

- The organization must have a migration business case. This document should be the result of a process to analyse their current state, desired future state, and the resulting gap analysis and remediation plan will provide executive guidance on the direction and velocity of the Migration Program. No matter what size of organization, making a unilateral decision to “go to the cloud” will miss out some important analysis that may result in an organization selecting the wrong migration method.

- The organization needs to have a well architected AWS target environment. Well-designed applications can run in poorly designed AWS environments. Deploying and managing a well architected AWS environment is a highly trained and skilled activity. The organization and its partners must be well versed in AWS Well Architected Framework and the AWS Cloud Adoption Framework to ensure the the best deployed target AWS environment.

To decide on a migration method, it’s important to understand the nuances between them, so for each of the remaining four methods we explore:

- Define the method

7



- Why do organizations choose the method? - What are the benefits of the method? - What are the risks of the method? - How to use the method - What you need, including costs


2.3 Important: Choosing the right Migration Partner A partner who specialises in one migration method is likely to recommend that as the primary, sometimes only, migration method. In these cases, it’s important to limit their involvement to the execution of migrations and not the decision-making step.

It is also important to choose a partner that provides staff that understand applications, automation and AWS: not just AWS systems administration. Migration of applications requires this complex mix of skills.

The alternative of “rolling your own migration” carries risk inversely proportional to your own staff experience of deploying and operating well architect AWS clouds and performing migrations. Some organizations leverage partners to “get the ball rolling” and transfer skills in an initial phase.

In summary, the critical capabilities of a Migration Partner are:

1. Expert in applications, automation and AWS. 2. Focused on customer experience and outcomes during migration. 3. Capability of multiple migration methods. 4. Ability to help operate the migrated applications. 5. Ability to evolve migrated applications to further exploit cloud for better business outcomes.


8



3 Migration method #1: Repurchasing (‘Drop and Shop’) Repurchasing can be the simplest, fastest and least-risk method of running applications in the cloud. An organization can eliminate a lot of migration effort and cloud set up by directly consuming applications via the AWS Marketplace.

Some examples of Repurchasing are:

- Swapping a self-run email system for an online email-as-a-service offering. - Swapping a self-built VPN server for a vendor-built appliance. - Instead of adopting the cloud service providers vanilla service, use a specialist third party appliance such as Web

Application Firewalls.

Uncovering these opportunities to Repurchase will happen through a Discovery process for the organization’s current application landscape.

For example, it is becoming increasingly unusual for organizations to build and operate their own email systems. As part of the Discovery Assessment, if email is found to be run in house then it is highly likely that a recommendation to Repurchase this as a Software-as-a-Service email offering is best value.

The Repurchasing method is constantly evolving and is likely to see significant growth from the current 5% of migrations to AWS (source: AWS). AWS Marketplace and Service Catalog are extending the Repurchasing options and now it is possible to avoid migrating fragile on-premises applications and instead Repurchase them in the AWS Marketplace. This is like an upgrade process where old configurations and data are migrated to the Repurchased platform.

It is also possible to mix Repurchasing with other migration methods. Perhaps it makes sense to buy a specialist appliance from AWS Marketplace to meet internal compliance rules (common example if firewall vendor selection), and then integrate that purchased appliance with components that have been migrated via another method.

3.1 Drivers of Repurchasing There are a couple of important tailwinds behind the cloud computing revolution.

Move to a consumption-based procurement

model

Consumers of technology wish to move to a more consumption-based procurement model, swapping lumpy three-year capital expenditure deals for monthly, no commitment pay-as-a-you-go models that efficiently ties their spend to their own income.

Retire legacy “enterprise” software

The “Enterprise” in enterprise software is no longer the “gold standard” of technology. With the rise of open source and the rapid pace of innovation in software, “enterprise software” is now seen as legacy, old, outdated, ugly, difficult to use. This means customers want to rotate their software stacks faster to remain competitive.

9



Repurchasing software through cloud procurement frameworks such as AWS Marketplace is how enterprises can refresh their application stack in a frictionless manner, which is a huge driver for enterprises. It eliminates long, complicated and expensive software procurement cycles like multi-stage RFI and RFP processes.

Trialing software via AWS Marketplace, and turning it off if it isn’t suitable, is a far more efficient method of software procurement.

In terms of application migration to AWS, organizations choose Repurchasing to prune down the applications they self-design, build and operate to eliminate costs and improve bottom line net income.

3.2 Benefits of Repurchasing There are several benefits with Repurchasing:

Let go of the past, grab the future Replace antiquated systems with modern appliances and SaaS.

Simplify procurement Buy appliances, BYOL, SaaS and Private Offers through one procurement mechanism.

Reduce in-house skills requirements The systems purchased are build buy specialists you don’t need to hire. SaaS means it is also run by people you don’t need to hire.

Reduce effort/increase speed of migration

The less there is to migrate, the faster, cheaper and less risky it is.

3.3 Risks of Repurchasing There are a number of risks when Repurchasing. Failing to consider and manage these can lead to poor migration experience and mismatched outcomes when the new, shiny purchased system simply doesn’t work.

Integrations and Dependencies If you replace your on-premises Active Directory system with a cloud version: which clients and applications must you reconfigure to use the new cloud service?

Procurement Friction Your Procurement team and procedures may be incompatible with this new way of buying applications. There are four methods they need to learn: Appliance (rented licence), Bring Your Own Licence, SaaS and Private Offer.

Finance Do finance know how to handle pay-as-you-go, unpredictable future costs?

Operations Can Operations “migrate” to administrate the purchased system? Migrations are often as much about people and process as it is about applications and data.

10



3.4 How to Repurchase As part of the Discovery Assessment, a list of known applications and their functions should be captured. This can be done with a qualified AWS partner to get the maximum value out of the process:

Step 1 Compare the list of known applications to those available in the AWS Marketplace.

Step 2 Understand current and future possible licensing and purchasing options.

Step 3 Plan how the Repurchased application will be paid for (with Finance) and operated (with Operations) and consumed (by Users).

Step 4 Plan the configuration and data migration to the new application, identify any blockers early.

Step 5 Repurchase the application using the best AWS Marketplace mechanism to a well architected AWS account.

Step 6 Configure the application and migrate data

Step 7 Test and Transition

3.5 What you need to Repurchase Repurchasing is quite different from Rehosting and Replatforming because you are dropping your current system and shopping for a new system. This reduces the number of actual migration activities to carrying forward configurations and migrating data. Data migrations should be easy on systems that have import features.

The key capabilities you need to make Repurchasing happen are:

- Procurement, finance and operations “on side”. - If you are replacing an existing application, have the in-house application expert (or partner) be involved in the

process. - An expert AWS Marketplace and AWS Service Catalog partner, or train someone up internally. This requires

expertise to navigate and execute properly. - A well-managed migration program with Repurchasing as a Work Package in the program, which a supporting

business case, allocated resources and timeline.

There is no standard timeline or budget for Repurchasing, it is highly variable according to the software but – in general – it is the fastest, simplest migration method.

11



4 Migration method #2: Rehosting (‘Lift and Shift’) Rehosting – aka Lift and Shift – is the relatively simple mechanism of copying application and data “bits” from outside the cloud, into the cloud. A classic example is copying virtual machines (that contain applications and data) and storage files (just data) across the internet or some other mechanism, into a pre-deployed target AWS account.

Rehosting is the currently the most common migration method due to its relative simplicity and speed compared to Replatforming and Refactoring. This method is the staple activity in a large legacy migration scenario where the organization is looking to quickly implement its migration and scale to meet compelling event such as evacuating a datacenter or hosting provider.

Most rehosting can – and should – be automated with tools such as AWS Server Migration Service (SMS) although you may prefer to do this manually as you learn how to apply your legacy systems to the cloud.

Rehosting is usually just the first step in a migration. Once in the cloud, the migrated applications will require more work to exploit the cloud.

4.1 Drivers for Rehosting Often Rehosting is chosen not because it is the best migration method, but because it is the most immediately convenient in response to a pain point or compelling event. Common examples are:

Number of migrations over time

A large number of applications to be migrated in a fixed time period means a simple, efficient and highly-parallel mechanism is required.

Compelling event or pain point

A compelling event such as immediate evacuation of a datacenter or hosting provider.

Available skills The available staff are familiar with virtualization and infrastructure-as-a-service so Rehosting matches their skill sets (whereas Replatforming and Refactoring need more skills)

Appliances Applications may be Commercial Off The Shelf packags contained in virtual machines

Unchanging Application

Some applications are in use but have no active roadmap or detail architecture, so it is cost efficient to lift-and-shift them rather than go thru expensive analysis

Adhoc Test Some environments are not well managed (on purpose) but are still important. It’s easier to lift-and-shift these to limit interruption.

However, the simplicity of Rehosting means it solves none of the cloud migration objectives of integrating with higher-order cloud services for better security, resilience, agility and cost reduction.

It’s a rule-of-thumb with cloud migrations that the more you put into the migration, the more benefits you get. But it costs you time, cost and effort to get there, and sometimes you are blessed with none of these!

12



4.2 Benefits of Rehosting If the organization is in a rush because of a compelling event or pain point and you have well understood applications and data on a cloud-compatible infrastructure (highly virtualized and easily accessible), then Rehosting can be the initially fastest and cheapest migration method.

Organizations may also find that applications are easier to re-architect once they are already running in the cloud. This happens partly because your organization will have developed better skills to do so and partly because the hard part - migrating the application, data, and traffic - has already been accomplished.

The business benefits of Rehosting are the limited cost, effort and complexity compared to Replatforming and Refactoring. This is a business-decision trade-off: save money and time now to “get to cloud” and deal with more cloud integrations later.

Summary of benefits to rehosting

- Speed of migration - Reduced risk (simplicity) - Broad AWS partner and tool ecosystem - Application, hypervisor and hardware agnostic - Can be highly automated with limited or no downtime - Imports configuration and scripts if these are not documented/hard to reverse engineer

4.3 Risks of Rehosting Rehosting appeals because it is at the simple end of the migration spectrum. But it isn’t without its risks and opportunity costs:

Migrating brittle processes When you migrate an application then you also inherit the operating system, possibly undocumented configurations, and “non-cloud” people and process with it. These are non-cloud, so it has to be clearly understood that no magic will happen in terms of transforming people and process through Rehosting.

Inefficient and expensive cloud consumption

Existing applications outside the cloud are often over-provisioned for peak load, a classic non-cloud approach that will need addressing through resizing later to avoid wasting money - but money will be wasted initially, offsetting the perceived savings with “simple Rehosting”

Rehosted applications are black boxes

Just copying the applications and data without understanding what’s in them means you are pulling everything into cloud, including malware or insecure configurations.

Unbudgeted/planned post-Rehosting “tidy up and fixes”

There are always post-Rehosting activities to take care of, these cost money, time and effort. Not doing them will also cost money (e.g. over-provisioned resources)

13



Ingest known and unknown problems

If the application has a problem outside the cloud, known or unknown, it will likely bring that problem to the cloud. Retiring technical debt is a big plus of more advanced migration methods like Replatforming and Refactoring, or drop-and-shop technique of Repurchasing.

Warning! Beware revenue hungry, one-trick Rehosting Specialists!

Organizations should be wary of cloud consultancies and service providers that push Rehosting as the only method of migration. It is ok to leverage these specialists for individual Rehosting work packages, but if they

are part of the discovery and decision making on what method to use then they will be naturally biased towards Rehosting just as to a hammer everything is a nail.

It is important to check that this isn’t because it is a fast path to revenue for the partner and that this is a higher priority than the customer’s cloud outcomes. Each application has to be assessed and the correct

migration method chosen, therefore the trajectory, velocity and landing zone for applications can be different.

If the partner is an infrastructure-focus, IaaS-only type partner then they will strongly prefer Rehosting because they don’t have the experience or skills at doing any of the other migration methods.

4.4 How to Rehost The steps to migrate an application by rehosting are as follows. If automation is used it is a good sign: it means the application and all its components are well understood and easily migratable. If automation is not possible, it suggests the application is not well understood and possibly fragile, leading to a risky migration and a brittle end product.

Step 1 Model the Rehosting process for this application, using a combination of AWS Server Migration Service, Data Migration Service and other tools.

Step 2 Ensure your staff (or Partner) are experts in these tools.

Step 3 Plan the Rehosting, allocating time and effort in the plan and understanding any potential service overlaps and outages.

Step 4 Using the preplanned tools, Rehost the application and its data to the pre-determined AWS account.

Step 5 Confirm the integrity of the migrated applications and data using techniques such as checksums as well as “eyeballing” the results.

14



Step 6 Test and Transition

4.5 What you need to Rehost As a Rehost is a simple, well-known process compared to Replatform and Refactor, it has a simple shape:

Budget Tool costs (free from AWS)

Data moving costs (free to inject in AWS, but maybe bandwidth or other transport costs)

Labour costs - budget £500-£800/day in the UK for an independent freelancer, but a qualified Partner may cost more (and do more)

Estimate AWS costs before Rehosting with AWS Simple Calculator

Tools AWS Migration Hub

AWS Application Discovery Service

AWS Server Migration Service

AWS Database Migration Service

Timeline This is always variable depending on the application, but the time components are normally consistent across migrations:

Time to set up and prepare the target AWS account ready for Rehosting

Time to copy applications and data to the cloud (multiple methods, different speeds and costs)

Time to verify the migrated applications and data

Time to reconfigure the migrated applications and “create the stack”

Testing and go live, don’t forget backout.

15



5 Migration method #3: Replatforming (‘Lift and Shape’) Replatforming is halfway between Rehosting and Refactoring. It gives some immediate, modest cloud benefits without a lot of risk.

Replatforming involves making a few cloud optimizations during migration. For example, there are some very common cloud services such as load balancers that can be immediately leveraged during migration to reduce the amount of virtual machines, configurations and operational processes to be migrated without changing the application.

Another common “shaping” activity during Replatforming is to just move your data and not your database to the cloud, and instead migrate to a managed relational database service such as Amazon Relational Database Service (RDS).

5.1 Drivers for Replatforming When an application is Replatformed into the cloud, it is modestly shaped to be more cloud-compatible but not completely cloud native.

The main business benefits of Replatforming is taking immediate, but modest, advantage of cloud by swapping common components -- and therefore benefiting from cost and performance improvements -- without the risk, complexity, cost and time of a full refactor.

Replatforming can reduce the cost of the migration programme and the cost of running the application while minimizing risk, which business leaders feel is a “sweetspot” and “we’re not betting the farm”.

As an example, a typical three-tier application that includes a load-balancer in a VM and a database layer in a VM can be adjusted to swap the load-balancer VM for an AWS managed load balancer, and the database VM for AWS managed Relational Database Service.

5.2 Benefits of Replatforming By making some cloud-friendly modifications to the application during migration it is possible to reduce the risks of the migration by avoiding migrating fragile scripts and configurations to the cloud. It also means that the application is exploiting cloud benefits from Day 1 once it is migrated.

Not difficult for an AWS expert

A good AWS engineer will know how to replace common application components with AWS services.

Immediate benefit from some cloud nativeness

Using higher-order services means less management cost, higher availability, costs that match consumption instead of “peak load”

Reduce the application/

data copying

The configuration is duplicated/improved on a replacement cloud service such as replacing Nginx in a VM with AWS Elastic Load Balancer.

16



5.3 Risks of Replatforming Not having the requisite AWS skills is one of the leading risks of Repatforming: replacing “known” self-managed components with poorly understood AWS equivalents. However, there are other ways to get Replatforming wrong:

None/Low/Poor AWS Skills

Choosing an inappropriate AWS service to replace a component (e.g. selecting the NoSQL DynamoDB to replace MySQL) or poorly configuring the AWS service.

Overly aggressive change

Every individual shape during Replatforming increases the risk of causing problems: be circumspect and choose common, well known shapings. Avoid exotic changes unless it’s a niche opportunity or unavoidable. The goal is a successful Replatform, not an exotic one.

Not using automation

It is possible to hand-craft Replatform an application, by clicking around the GUI and manually making changes and copies. A better answer is to model the application needs using an automation platform, and then make modifications to the model to represent the Replatform shapings

5.4 How to Replatform It is possible to manually Replatform an application to AWS but the best method is to use an automated method that can describe the application as code, making adjustments transparent and testable to reduce risk and effort.

Step 1 Analyse the application, understanding its components, dependencies, operational needs and “normal” behaviour including known problems.

Step 2 Model the application using a blueprinting technology that captures the components, their configurations and integrations with each other.

Step 3 Consider the AWS Well Architected Framework as part of the migration, which is a great help to make sure the application is aligned with best practices such as security, cost and operations: what is possible/aligned now, and what can be done later in the cloud?

Step 4 Shape a limited selection of the components to leverage cloud services such as AWS Load Balancer and Relational Database Services, as well as reducing potential issues by replacing brittle scripts by more automation or managed services.

Step 5 Deploy the modelled application including data migration (usually from a test system) to an AWS account.

Step 6 Test the deployed application, make adjustments.

Step 7 Do the Transition including network changes, data migration and, operations onboarding.

17



5.5 What you need to Rehost To do a Replatform, you need a bit more than a Rehost across all the three vectors of budget, tools and timeline.

Budget Tool costs (free from AWS), add any specialist application modelling software such as Cloudsoft AMP

Data moving costs (free to ingest in AWS, but you might incur bandwidth or other transport costs)

Labour costs - need someone who understands more than just virtualization and IaaS. Requires someone qualified at AWS Professional level and experienced/expert at AWS services. May have to exceed the budget of £500-£800/day in the UK for an independent freelancer, and a qualified Partner may cost more (and do more)

Estimate AWS costs before Rehosting with AWS Simple Calculator

Tools AWS Migration Hub

AWS Application Discovery Service

AWS Server Migration Service

AWS Database Migration Service

Application Modelling/Blueprinting

Timeline This is always variable depending on the application, but the time components are normally consistent across migrations:

Time to set up and prepare the target AWS account ready for Rehosting

Time to model the application using the automation software.

Time to copy some application components and data to AWS

Time to verify the migrated applications and data

Time to configure the replacement AWS services like ELB or RDS.

Time to deploy automated stacks and refine them

Testing and Transition

18



6 Migration method #4: Refactoring (“Cloud Native”) Refactoring is a method to transform a non-cloud application into a cloud-native application. It is cloud-compatibility turned up to 10. This method transforms everything about the application: it’s components, the application code, and the data itself.

- Components are swapped out for higher-order AWS services - Code is deconstructed and decoupled into modern cloud services such as Functions-as-a-Service like AWS Lambda, a

stepping stone to that can be containers. - Data stores are chosen to suit the different types of data. Instead of a single monolithic RDBMS for all of the

application functions, an application might now consume multiple database sources including AWS DynamoDB (NoSQL), AWS Aurora (Managed RDBMS) and even AWS Redshift (Data Warehousing)

6.1 Drivers for Refactoring Typically, this is driven by a strong business need to add features, scale, or performance that would otherwise be difficult to achieve in the application’s existing environment. If your organization is looking to boost agility or improve business continuity by moving to a service-oriented architecture (SOA) this strategy may be worth pursuing - even though it is often the most expensive solution.

6.2 Benefits of Refactoring All of the benefits of refactoring are delivered in the future, this is a non-trivial method. By turning an application into a cloud-native application it will unlock all of the benefits of the cloud more than any other migration method.

Long term cost reduction

Matching resource consumption demand, in some cases down to per-transaction, eliminating waste.

Increase resilience By decoupling the application components and wiring together highly-available and AWS managed services.

Responsive to business events

Leveraging the auto-scaling features of AWS services that scale up and down according to demand.

Exploit AWS innovation Inherit improvements in AWS services, and be well placed to move to new services, such as a move from AWS Aurora to Aurora Serverless.

6.3 Risks of Refactoring Cloud native increases the coupling between your application and AWS. To get the most AWS benefits, you have to tie your application into their higher-order services and away from EC2 instances and standard storage. This can increase the feeling of lock-in, though other leading public cloud providers offer similar higher-order services.

19



Lock-in The more cloud-native your application is, the more tightly coupled it is to the cloud you are in.

Skills Refactoring requires the highest level of application, automation and AWS skills and experience. Refactoring is not for beginners!

Time Because refactoring is more complicated in terms of changing from a non-cloud application to a cloud-native application, it can also be the longest piece of work.

Getting it wrong Because Refactoring requires changing everything about the application, it’s the maximum exposure to getting it wrong. Each wrong thing can cause delays, cost increases and potentially outages.

6.4 How to Refactor This is a highly variable activity, dependent on the current application complexity (is it a monolithic, single-threaded Ruby application with one database or a distributed Java application that has integrations to separate on-premises systems?).

During the Discovery Assessment process it should be estimated how long this might take, but it’s fair to say that anything between three to six months is average

20



7 Summary The experience and outcome of migrating to the cloud is unique to every organization, but there is commonality in approach as outlined in this white paper.

When an organization has an opportunity to migrate applications and data to AWS the follow a high-level process of creating a Business Case, doing Application Discovery, then choosing Migration Methods and executing them. Along the way these organizations have a wide range of factors to consider and activities to undertake as described in this white paper.

In Cloudsoft’s experience, there are a wide range of positive and negative aspects of migrating to AWS and for this reason, and for business risk management for any migration program, it’s important for organizations to have an experienced partner to assist with part or all of their migration strategy.

Cloudsoft’s criteria for an ideal AWS partner is:

- Experts in applications, automation and AWS. - Focused on customer experience and outcomes during migration. - Capability of multiple migration methods. - Ability to help operate the migrated applications. - Ability to evolve migrated applications to further exploit cloud for better business outcomes.

Contact us at Cloudsoft to talk about your migration strategy. We provide a free initial consultation to help get you started and we’d be delighted to help you with some or all of your migration programme.

what everyone needs to know about migrating applications ... · this manager’s guide paper...

Documents