A go-to AWS migration checklist for DevOps-ready enterprises

1. Application architecture prep

A good AWS migration checklist starts with an application review. The migration team must decide if the application is cloud-ready. In addition, it must establish business constraints and cost estimates.

 List the pros and cons of moving this application to AWS. What are the business and technological drivers? Contact all of the appropriate leaders involved in migration decisions.

 Assess the application's cloud readiness. Is it designed to scale flexibly, with separate components, or is it monolithic? Will it need refactoring prior to the migration? Will the entire application live on AWS, or only some components, such as the front end?

 Delineate which, if any, application components need to stay in-house. Define the technological and/or business drivers for non-migration. Create a plan to migrate these in-house components to the public cloud in the future, if applicable. Evaluate whether AWS Outposts, the cloud provider's managed on-premises infrastructure offering, is a fit for these components. Outposts launches in late 2019, and adds another layer of decision making for AWS migrations.

 Evaluate application databases. Will databases migrate to Amazon Relational Database Service or Amazon Aurora, or should the organization port an Oracle or Microsoft SQL Server deployment onto EC2? Alternatively, will the migration team keep the database or databases on premises and only move the processing or app execution to AWS?

 Secure data. Plan how the application will input and output data securely to these cloud end points, either over the public internet or through dedicated fiber. Establish how data will be protected at rest and in motion and vet this design with the security team.

 Map application components' integrations and dependencies. Migration teams must understand how workflows travel through components and where potential issues lie. AWS offers an Application Discovery Service to run against an on-premises deployment, or organizations can rely on application dependency maps and asset tracking tools already in place in their data centers.

 Estimate costs. The cloud isn't necessarily cheaper, and teams must account for the costs of data transfers, storage, compute usage and scaling. AWS offers the Simple Monthly Calculator for various services, such as EC2 instances, Elastic Load Balancing and more, with example application deployments. An organization can also turn to third-party cost management tools.

Organizations can get caught up in a single path to application migration -- refactoring everything for optimal cloud use, for example. To be truly successful, you need a combination of cloud, Agile and DevOps, but any technological moves must be assessed in accordance with project goals, Buchner said. If the application is set to retire in two years, lift and shift as needed. But if the application is an investment for the business, take the extra time to optimize it.

2. Hosting on AWS

Once the migration team understands its resource and operations demands, it can determine how its applications should be hosted in the cloud. Use this section of the AWS migration checklist to evaluate AWS hosting choices.

 Define an infrastructure strategy. Does the application require a dedicated Amazon VPC or should it deploy to multi-tenant instances? AWS recommends setting up an AWS Landing Zone account with multiple users to enable the migration.

 Set up application instance types. These instances must fit the application's resource demands and scaling requirements. Examples include lower-cost T3 burstable VMs, general purpose M5  instances and other EC2 instance types optimized for compute, storage or otherwise. The migration team could also move to higher-level AWS choices like Elastic Beanstalk or even AWS Lambda for serverless execution.

 Build in scalability. Administrators can configure apps to scale automatically with AWS Auto Scaling, but they need to be mindful of the cost implications of any added resource consumption. Implement limits via manual adjustment or based on a scaling policy. Plan application scaling in conjunction with a content delivery network, such as AWS CloudFront or another third-party tool such as CloudFlare.

 Set up storage to meet varying data demands and redundancy requirements. AWS offers S3 object storage, Elastic Block Store and other storage services, including S3 Glacier for archives. Implement storage lifecycle management that moves data between hot and cold storage tiers. To migrate a large amount of data onto AWS, consider Snowball, a physical device that is shipped to users and carries the application data to AWS. 

 Assign the hosting environment to suit geographic restrictions or requirements. To reduce latency, for example, the application should deploy in AWS Regions close to major customer bases. Or, for compliance with data residency laws, storage should be tethered to one Region.

Organizations accustomed to sizing hardware resources on premises can get overly precise with instance planning, Buchner warned. That's an old way of thinking. "In the cloud, you can change [resource allocation] in a matter of minutes, so just make the best guess, run it and optimize from there," he said.

3. Application deployment

When server maintenance and management give way to standardized cloud instances, organizations should shift to automated operations and infrastructure as code (IaC). Make the cloud migration worthwhile with a well-planned deployment toolkit and process that combines Agile and DevOps methodologies.

 Migrate the application and related components onto AWS. Amazon has a range of native services for migration, including AWS Database Migration Service, AWS Server Migration Service, CloudEndure Migration and VMware Cloud on AWS.

 Set up a CI/CD pipeline. These pipelines deploy the application and updates to AWS resources. AWS offers CodeBuild and CodePipeline natively and supports independent pipelines, such as an integrated suite of tools connected by Jenkins.

 Create IaC templates for application infrastructure configuration. Use native CloudFormation with CloudFormer templates, or third-party tools such as Terraform by HashiCorp. These enable rapid deployment and standardization.

If you still do Waterfall development, don't let Agile and DevOps implementation create a barrier to a cloud migration. DevOps adoption is harder on premises, and tooled differently than cloud-based pipelines, Buchner said. So rather than learn DevOps twice, start with the cloud step, and use it to propel Agile and DevOps growth within the company.

4. Operations and support

A successful cloud migration is the start, not the finish, of an application lifecycle. The rest of the lifecycle -- monitoring, incident detection and response and resource management -- is where the team can prevent performance and security problems, and fine-tune DevOps processes.

 Update application performance monitoring. Complete the DevOps feedback loop with cloud operations monitoring. Establish new baseline performance metrics for the application, especially if components were re-architected for cloud services. Set new thresholds for alerts, and investigate third-party monitoring tools versus AWS CloudWatch.

 Monitor infrastructure resources based on the shared-responsibility model. The physical infrastructure performance and availability is now AWS' responsibility, but everything on top of that falls to your IT operations teams. They must know when the application is experiencing problems, when their instances are misconfigured or have bottlenecks, and when AWS' data centers are to blame. Track issues on the AWS Service Health Dashboard page.

 Establish preventative security measures. The security perimeter changes when an application is moved to the public cloud. What firewalls are in place? Could virtual firewalls effectively control instance traffic? Take the time to read about major IT security breaches and how to avoid the same fate.

 Enable security monitoring and hardening. Use penetration tests, vulnerability scans and other detective efforts. Enterprises with multiple AWS accounts should look into governance options, such as AWS Control Tower.

 Set up log aggregation and archives. Organizations with hybrid cloud applications find centralized log management difficult, due to the disparate sources of log information. They might need separate tools to aggregate logs from AWS and the on-premises setup.

 Document and practice incident response procedures. Cloud management differs greatly from on-premises tasks, where administrators control the servers and can even physically troubleshoot them. Make use of on-demand resources as a landing place to instantly roll back any problematic updates.

 Revisit application backup and disaster recovery procedures. Either put the disaster recovery site in another AWS Region or Availability Zone or ensure the app can fail over to on-premises servers.

 Curb sprawl. Provisioning on AWS is easier than on-premises, so  track deployment size and scaling limits periodically post-migration. Adjust as necessary to meet demand and stay on budget. AWS' automatic resource scaling can mask app performance issues, so examine bills for unexpected usage.

Security is a concern for most organizations moving applications from on premises to AWS. Start with simple checks, with the AWS Trusted Advisor tool for instance, to catch what Buchner calls "glaring security holes." There are also sophisticated commercial security audit tools. The next step up is a roughly three-hour review against the AWS Well-Architected Framework that measures for operational excellence, security, reliability, performance efficiency and cost optimization. And in the case of high-security applications, organizations can bring in security specialists to audit the application, network, access control and other attack surfaces.

5. Project management and cost

An AWS migration checklist doesn't end when your project is hosted on the cloud. Project management considerations, such as app evaluation and team decisions, matter even after the migration. Revisit them frequently to ensure the project is on track and remember to train, train and train some more.

 Define the goals and scope of the migration long-term. How will the company manage AWS accounts and spending once more applications migrate? Will each department manage its own AWS deployment, or will cloud adoption come under centralized control? How will decisions made for this project propagate throughout the organization?

 Build a schedule based on the migration plan. Account for holidays and relevant business initiatives to create a realistic timeline.

 Assess the staff's AWS skills and train accordingly. Ensure skills development is specifically related to a team member's daily tasks. Capture training sessions for future use and ongoing improvement.

 Select the right tools and services. Tools should fit the organization's requirements, and companies need to train administrators to use them. Reevaluate tools frequently as new features emerge and the vendor landscape changes. Poll users to ensure tools are working as intended and fully utilized.

 Formalize organizational communication and knowledge sharing. Everyone needs to be on the same page -- application architects, developers, admins and security ops specialists, as well as application owners and business leadership. Centralize runbook documentation, IaC templates and other relevant knowledge for the project in a wiki or other repository.

 Use cost estimates and simulations to set a post-migration budget. Cloud spending can quickly get out of control. Ensure the budget accounts for variable and cyclical demand and that there's a way to ring alarm bells when the app deviates from the norm.

When businesses move to the cloud, they must predict account management over time. Few address this concern at the beginning, and a medium-sized business can easily end up with 120 AWS accounts, Buchner said. More accounts mean more passwords, more overhead, bigger budget lines and potentially unneeded complexity. Businesses can regroup accounts with AWS Organizations and probably need to devote time to it after some successful early forays into the cloud.

Buchner advises separating accounts in three scenarios: If the accounts belong to independent teams or business units with no overlap, when the business must know exact costs associated with different workloads, and for security and compliance purposes when diverse applications run on AWS.