Amazon Migration-1

Phases of migration

Phase 1: Prepare

You identify the interdependencies between your applications and databases. You also analyze the database workloads to determine the migration categories: from simple rehost (homogeneous) migration to re-architect (heterogeneous) migration.

These tasks are discussed in the following sections:

  Identifying dependencies àBy asking questions such as

§  Is this database directly accessed by any other application?

§  Is the database using database links to fetch data from other databases?

    Qualifying workloads à Understand the current database workload

§  workload qualification tool called AWS Workload Qualification Framework (AWS WQF)

§  It helps identify the complexity of your Oracle and Microsoft SQL Server database migration by analyzing database schemas and code objects, application code, dependencies, performance characteristics.

Phase 2: Plan 

The 6 most common application migration strategies we see are:

        Migration Readiness and Planningà(MRP) is a method that consists of tools, processes, and best practices to prepare an enterprise for cloud migration. MRP describes a specific program that AWS Professional Services offers

         

Phase 3: Migrate (p. 8)

Phase 4: Operate and optimize (p. 13)

Move to Infrastructure as a Service (IaaS):

Move to Platform as a Service (PaaS):

Choosing a deployment model that aligns with business requirements is essential to make sure that any data migration is both smooth and successful and delivers business value in terms of performance, security, and ROI.

https://cloud.netapp.com/blog/aws-migration-5-key-challenges-and-solutions

General Purpose

https://aws.amazon.com/rds/instance-types/

Intuit story: Automate migration from on-premises MySQL to Amazon Aurora

https://aws.amazon.com/blogs/database/intuit-story-automate-migration-from-on-premises-mysql-to-amazon-aurora/

AWS Managed Services checklist

When selecting the best architecture for your application, consider the following questions. Determine whether your answers make a better case for building your own solution then check the appropriate box. Completing this simple checklist will help you make a more informed decision from the start.

Operational work: How much time and work does it take to maintain your stack (including version upgrades,security patching, hardware updates, software deployments, etc.)?

Infrastructure costs, now and at scale: How much will it cost to run your technology stacks at each stage of growth for your company?

Simplicity: Would the simplicity of managed services create significant value as you onboard more technologies, vendor products, and software to your application?

Time to market: Which choice will ultimately allow you to build features faster for your customers?

Agility: Which choice allows you to move quicker, shift gears when needed, and innovate with greater freedom?

Reliability: Can you maintain application reliability on your own, or would having highly skilled AWS experts focused on your implementation and operations be the better choice?

Availability: Does your application always need to be up and running? Can your infrastructure maintain high availability as your company grows, or would highly-available-by-default AWS Managed Services give you more peace of mind?

Security: How robust will your security posture be if you roll your own service? At AWS, security is our number one priority across all our infrastructure and services.

Portability: Will you need to move your application on premises or to another cloud provider?

Customization: Do you need a high level of customization? If you choose to build, you can tailor everything to your exact needs—however, AWS Managed Services can enable a higher degree of customization than you might think.