# Prioritized applications assessment One of the key outcomes of the previous stage, [portfolio discovery and initial planning](portfolio-discovery-initial-planning.md), was to [prioritize a subset of applications](prioritization-and-migration-strategy.md#prioritizing-applications) for detailed assessment. This section explores the detailed assessment of applications. Looking at the details of a few applications early on will drive acceleration. The process of assessment and to-be architecture design surfaces potential blockers and clarifies important tasks that precursors to the larger-scope migration. These tasks include gathering requirements to establish AWS foundations, such as the landing zone on AWS, or to extend and validate the existing landing zone. This assessment is also the time to consider the steps and the strategy for migration. The primary outcomes of this stage are the following: + Validated list of prioritized applications + Documented current state architecture + Documented initial target architecture and migration strategy for migration candidates + Identified migration patterns and tooling + Documented platform requirements (security, AWS infrastructure, and operations) + Documented cutover considerations for migration planning + Estimated AWS run rate # Understanding detailed assessment data requirements The following table describes the information required to obtain a complete portfolio view of the applications in the migration and their associated infrastructure. The tables use the following abbreviations: + R, for required + O, for optional + N/A, for not applicable **Applications** | **Attribute name** | **Description** | **Discovery, design, and migration strategy** | **Estimated run rate** | **Recommended fidelity level (minimum)** | | --- |--- |--- |--- |--- | | Unique identifier | For example, application ID. Typically available on existent CMDBs or other internal inventories and control systems. Consider creating unique IDs whenever these are not defined in your organization. | R | O | High | | Application name | Name by which this application is known to your organization. Include commercial off-the-shelf (COTS) vendor and product name when applicable. | R | R | High | | Is COTS? | Yes or No. Whether this is a commercial application or internal development | R | R | High | | COTS product and version | Commercial software product name and version | R | R | High | | Description | Primary application function and context | R | O | High | | Criticality | For example, strategic or revenue-generating application, or supporting a critical function | R | O | High | | Type | For example, database, customer relationship management (CRM), web application, multimedia, IT shared service | R | O | High | | Environment | For example, production, pre-production, development, test, sandbox | R | R | High | | Compliance and regulatory | Frameworks applicable to the workload (for example, HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) and regulatory requirements | R | O | High | | Dependencies | Upstream and downstream dependencies to internal and external applications or services | R | N/A | High | | Infrastructure mapping | Mapping to physical and/or virtual assets that make up the application | R | R | High | | License | Commodity software license type (for example, Microsoft SQL Server Enterprise) | R | R | High | | Cost | Costs for software license, software operations, and maintenance | N/A | R | Medium-high | | Business unit | For example, marketing, finance, sales | R | O | High | | Owner details | Contact information for application owner | R | O | High | | Architecture type | For example, web application, 2-tier, 3-tier, microservices, service-oriented architecture (SOA) | R | R | High | | Recovery point objective (RPO), recovery time objective (RTO), and /service-level agreement (SLA) | Current service- management attributes | R | R | High | | Revenue-generating Application or business-strategic application? | Yes, if application directly or indirectly influences company revenue or is considered strategic by the business. | R | O | Medium-high | | Number of users (concurrent) | For example, internal, or external users or, internal and/or external users/customers | R | R | Medium-high | | User location | Origin of user sessions | R | R | Medium-high | | Risks and issues | Known risks and issues | R | O | Medium-high | | Migration considerations | Any additional information that could be relevant for migration | R | R | Medium-high | | Migration strategy | For example, one of the AWS 6 Rs for migration | R | R | Medium-high | | Database details | For example, partitioning, encryption, replication, extensions, Secure Sockets Layer (SSL) support | R | R | High | | Support teams | For example, application operations team name | R | O | Medium-high | | Monitoring solution | Product used to monitor this application | R | O | Medium-high | | Backup requirements | Required backup schedule in AWS | R | R | Medium-high | | DR information | For example, disaster recovery components for this application | R | R | Medium-high | | Target AWS requirements | For example, components, account placement, networking, security | R | R | High | **Infrastructure** | | | | | | | --- |--- |--- |--- |--- | | **Attribute Name** | **Description** | **Discovery, design, and migration strategy** | **Estimated run rate** | **Recommended fidelity level (minimum)** | | Unique identifier | For example, server ID. Typically available on existing CMDBs or other internal inventories and control systems. Consider creating unique IDs whenever these are not defined in your organization. | R | O | High | | Network name | Asset name in the network (for example, hostname) | R | O | High | | DNS name (fully qualified domain name, or FQDN) | DNS name | O | O | Medium-high | | IP address and netmask | Internal and/or public IP addresses | R | R | High | | Asset type | For example, physical or virtual server, hypervisor, container, device, database instance | R | R | High | | Product name | Commercial vendor and product name (e.g., VMware ESXi, IBM Power Systems, Exadata) | R | R | High | | Operating system | For example, REHL 8, Windows Server 2019, AIX 6.1 | R | R | High | | Configuration | Allocated CPU, number of cores, threads per core, total memory, storage, network cards | R | R | High | | Utilization | CPU, memory, and storage peak and average. Database instance throughput. | R | R | High | | License | Commodity license type (for example, RHEL Standard) | R | R | High | | Is shared infrastructure? | Yes or No to denote infrastructure services that provide shared services such as authentication provider, monitoring systems, backup services, and similar services | R | O | High | | Application mapping | Applications or application components that run in this infrastructure | R | O | High | | Communication data | For example, server to server at a process level | R | N/A | Medium-high | | Target AWS requirements | For example, instance types, account, subnets, security groups, routing | R | R | High | | Migration strategy, patterns, and tools | For example, one of the 6 Rs for migration, specific technical pattern, migration tooling | R | O | High | | Risks and issues | Known risks and issues | R | O | Medium-high | # Detailed application assessment The goal of a detailed application assessment is the complete understanding of the targeted application and its associated infrastructure (compute, storage, and network). High-fidelity data is necessary to avoid pitfalls. For example, it is common for organizations to assume that they fully understand the application. This is natural, and it's true in many cases. However, to minimize risk to the business, it is important to validate institutional knowledge and static documentation by obtaining programmatic data as much as possible. This will take care of the heavy lifting of the discovery process. You can focus on the data elements that come from alternative sources, such as business-specific information, strategic roadmaps, and others. The key is to avoid last-minute changes during and after migration. For example, when migrating, it's important to avoid changes based on unidentified dependencies that might require the inclusion of a server into an ongoing migration wave. Shortly after migration, it's important to avoid changes based on the associated platform requirements to allow traffic or deploy additional services. These kinds of unplanned changes increase the risk of security and operational issues. We highly recommend using programmatic discovery tooling to validate traffic patterns and dependencies when performing detailed application assessments. At the beginning of the assessment, you must identify the application stakeholders. These are typically the following: + Business unit leads + Application owners + Architects + Operations and support + Cloud-enablement teams + Specific platform teams such as compute, storage, and networks There are two approaches for detailed discovery. Top-down discovery starts with the application, or even with the user, and goes all the way down to the infrastructure. This is the recommended approach when the identification of the application is clear. Conversely, bottom-up discovery starts with the infrastructure and goes all the way up to the application or service and its users. This approach is useful when migration programs are driven by infrastructure teams and when application-to-infrastructure mapping is unclear. In general, you are likely to use a combination of both. To dive deep into an application, existing architecture diagrams are good start. If these are not available, create one based on current knowledge. Do not underestimate the importance of this task, even for simple rehost or relocate migration strategies. Plotting architectural diagrams helps you to identify inefficiencies that can be quickly addressed with minor changes when in the cloud. Depending on whether you are performing a top-down or bottom-up approach, the initial diagram will plot application components and services or infrastructure components such as servers and load balancers. After the main components and interfaces have been identified, validate them with programmatic data from discovery tools and application performance monitoring tools. The tools must support dependency analysis and provide communication information between components. Each component that makes up this application must be identified. Next, document dependencies to other applications and services, both internal and external. In the absence of tooling to validate dependencies and mapping, a manual approach is required. For example, you can log into infrastructure components and run scripts to collect communication information such as open ports and established connections. Likewise, you can identify running processes and installed software. Don't underestimate the effort required for manual discovery. Programmatic tooling can capture and report most dependencies in a few days, except those that occur at greater intervals (typically a small percentage). Manual discovery can take weeks to collect and merge all data points, and it can still be prone to errors and missing data. Proceed to obtain the information specified in the [data requirements](understanding-detailed-assessment-data-requirements.md) section for each prioritized application and the mapped infrastructure. Next, use the following questionnaire to guide you through the detailed assessment process. Meet with the identified stakeholders to discuss the answers to these questions. ## General + What is the criticality level of this application? Is it revenue generating? Is it a business-strategic or supporting-business application? Is it a core infrastructure service shared by other systems? + Is there any ongoing transformation project for this application? + Is this an internally or externally facing application? ## Architecture + What is the current architecture type (for example, SOA, microservices, monolith)? How many tiers does the architecture have? Is it tightly coupled or loosely coupled? + What are the components (for example, compute, databases, remote storage, load balancers, caching services)? + What are the APIs? Describe these, including API name, operations, URLs, ports, and protocols. + What is the maximum latency tolerated between components and between this and other applications or services? ## Operations + In what locations does this application operate? + Who operates the application and infrastructure? Are these operated by internal or AWS Partner teams? + What happens if this application goes down? Who is affected? What is the impact? + Where are users or customers located? How do they access the application? What is the number of concurrent users? + When was the last technology refresh? Is a refresh scheduled in the future? If so, when? + What are the known risks and issues for this application? What is the history of outages and medium-severity and high severity incidents? + What is the usage cycle (in business hours)? What is the operating time zone? + What are the change freeze periods? + What solution is used to monitor this application? ## Performance + What does the collected performance information show? Is usage spiky or constant and predictable? What is the time frame, interval, and date of the available performance data? + Are there scheduled batch jobs that are part of or interact with this application? ## Software lifecycle + What is the current rate of change (weekly, monthly, quarterly, or yearly)? + What is the development lifecycle (for example, test, development, QA, UAT, pre-production, production)? + What are the deployment methods for application and infrastructure? + What is the deployment tooling? + Does this application or infrastructure use continuous integration (CI)/continuous delivery (CD)? What is the level of automation? What are the manual tasks? + What are the licensing requirements for the application and infrastructure? + What is the service level agreement (SLA)? + What are the current test mechanisms? What are the test stages? ## Migration + What are the migration considerations? At this point, note any considerations when migrating this application. For a more complete and accurate assessment, obtain answers to this question from the different stakeholders. Then contrast their knowledge and opinions. ## Resiliency + What is the current backup method? What products are used for backup? What is the backup schedule? What is the backup retention policy? + What are the current recovery point objective (RPO) and recovery time objective (RTO)? + Does this application have a disaster recovery (DR) plan? If so, what is the DR solution? + When was the last DR test? ## Security and compliance + What are the compliance and regulatory frameworks that apply to this application? What are the last and next audit dates? + Does this application host sensitive data? What is the data classification? + Is the data encrypted in transit or at rest, or both? What is the encryption mechanism? + Does this application use SSL certificates? What is the issuing authority? + What is the authentication method for users, components, and other applications and services? ## Databases + What databases does this application use? + What is the typical number of concurrent connections to the database? What are the minimum number and maximum number of connections? + What is the connection method (for example, JDBC, ODBC)? + Are connection strings documented? If so, where? + What are the database schemas? + Does the database use custom data types? ## Dependencies + What is the dependency between components? Note any dependencies that can't be resolved and that will require migrating the components together. + Are components split across locations? What is the connectivity between these locations (for example, WAN, VPN)? + What are the dependencies of this application to other applications or services? + What are the operational dependencies? For example, maintenance and release cycles such as patching windows. # AWS application design and migration strategy Designing and documenting the future state of your application is a key migration success factor. We recommend creating a design for any type of migration strategy, no matter how simple or complex. Creating the design will surface potential blockers, dependencies, and opportunities to optimize the application even in cases where the architecture is not expected to change. We also recommend approaching the future state of the application in AWS with a migration strategy lens. At this stage, make sure that you define what the application will look like in AWS as a result of this migration. The resulting design will serve as a base for further evolution after the migration. The following list contains resources to aid the design process: + [AWS Architecture Center](https://aws.amazon.com/architecture/) combines tools and guidance, such as the AWS Well-Architected Framework. Also, it provides reference architectures that you can use for your application. + [The Amazon Builders' Library](https://aws.amazon.com/builders-library/) contains several resources about how Amazon builds and operates software. + [AWS Solutions Library](https://aws.amazon.com/solutions/) offers a collection of cloud-based solutions, vetted by AWS, for dozens of technical and business problems. It includes a large collection of reference architectures. + [AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/) provides strategies, guides, and patterns that aid the design process and migration best practices. + [AWS Documentation](https://docs.aws.amazon.com/) contains information about AWS services, including User Guides and API References. + [Getting Started Resource Center](https://aws.amazon.com/getting-started/) provides several hands-on tutorials and deep dives to learn the fundamentals so that you can start building in AWS. Depending on where you are in the cloud journey, AWS foundations might already exist. These AWS foundations include the following: + AWS Regions have been identified. + Accounts have been created or can be obtained on demand. + General networking has been implemented. + Foundational AWS services have been deployed within the accounts. Conversely, you might be early in the process, and AWS foundations are not yet established. A lack of established foundations could limit the scope of your application design or require further work to define them. If this is the case, we recommend defining and implementing the foundational design of the landing zone in parallel with the application design work. The application design helps to identify requirements such as AWS account structure, networking, virtual private cloud (VPCs), Classless Inter-Domain Routing (CIDR) ranges, shared services, security, and cloud operations. [AWS Control Tower](https://aws.amazon.com/controltower/) provides the easiest way to set up and govern a secure, multi-account AWS environment, called a landing zone. AWS Control Tower creates your landing zone using AWS Organizations, which provides ongoing account management and governance and implementation of AWS best practices based experience working with thousands of customers as they move to the cloud. ## Application future state Start by establishing the initial migration strategy for this application. At this point, the strategy is considered initial because it could change as part of the future state design, which can uncover potential limitations. To validate initial assumptions, see the [6 Rs decision tree](prioritization-and-migration-strategy.md#migration-r-type). Also, document potential migration phases. For example, will this application be migrated in a single event (all components are migrated at the same time)? Or is this a phased migration (some components are migrated later)? Note that migration strategies for a given application might not be unique. This is because multiple R types could be used to migrate the application components. For example, the initial approach could be to lift and shift the application without changes. However, an application's components might reside in different infrastructure assets that might require diverse treatments. For example, an application is made up of three components, each running on a separate server, and one of the servers runs a legacy operating system that isn't supported in the cloud. That component will require a replatform approach, while the other two components, running in supported server versions, can be rehosted. It is key to assign a migration strategy to each application component and associated infrastructure that is being migrated. Next, document the context and problem, and link existing artifacts that define the current state: + Why is this application being migrated? + What are the proposed changes? + What are the benefits? + Are there any major risks or blockers? + What are the current downsides? + What is in scope and out of scope? ## Repeatability Throughout the design work, consider how this solution and architecture for this application can be reused for other applications. Can this solution be generalized? ## Requirements Document the functional and nonfunctional requirements for this application, including security. This includes current and future state requirements, depending on the migration strategy chosen. Use the information gathered during the detailed application assessment to guide this process. ## To-be architecture Describe the future architecture for this application. Consider creating a reusable diagram template that contains building blocks for your source environment (on-premises) and target AWS environment (for example, target AWS Region, account, VPCs, and Availability Zones). Create a table of components that are being migrated and components that will be new. Include other applications and services (either on premises or in the cloud) that interact with this application. The following table lists example components. It does not represent a reference architecture or vetted configuration. | **Name** | **Description** | **Details** | | --- |--- |--- | | Application | External service (inbound connection) | Service consumes data from exposed API. | | DNS | Name resolution (internal) | Amazon Route 53 deployed as part of baseline account settings | | Application Load Balancer | Distributes traffic among backend services | Replaces on-premises load balancer. Migrate Pool A. | | Application security | DdoS protection | Implemented by using AWS Shield | | Security group | Virtual firewall | Limit access to application instances on port 443 (inbound). | | Server A | Front-end | Rehost, using Amazon Elastic Compute Cloud (Amazon EC2). | | Server B | Front-end | Rehost using Amazon EC2. | | Server C | Application logic | Rehost using Amazon EC2. | | Server D | Application logic | Rehost using Amazon EC2. | | Amazon Relational Database Service (Amazon RDS) – Amazon Aurora | Database | Replaces servers E and F | | Monitoring and alerting | Change control | Amazon CloudWatch | | Audit logging | Change control | AWS CloudTrail | | Patching and remote access | Maintenance | AWS Systems Manager | | Resource access | Secure access control | AWS Identity and Access Management (IAM) | | Authentication | User access | Amazon Cognito | | Certificates | SSL/TLS | AWS Certificate Manager | | API 1 | External API | Amazon API Gateway | | Object storage | Image hosting | Amazon Simple Storage Service (Amazon S3) | | Credentials | Management and hosting of credentials | AWS Secrets Manager | | AWS Lambda function | Retrieval of database credentials and API keys | AWS Lambda | | Internet gateway | Outbound internet access | Internet gateway to a VPC | | Private subnet 1 | Backend and DB | Availability Zone 1 – VPC 1 | | Private subnet 2 | Backend and DB | Availability Zone 2 – VPC 1 | | Public subnet 1 | Front-end | Availability Zone 1 – VPC 1 | | Public subnet 2 | Front-end | Availability Zone 2 – VPC 1 | | Backup services | Databases and EC2 instance backup | AWS Backup | | DR | Amazon EC2 resiliency | AWS Elastic Disaster Recovery | After the components have been identified, plot them in a diagram using your preferred tool. Share the initial design with the key application stakeholders, including application owners, enterprise architects, and the platform and migration teams. Consider asking the following questions: + Does the team generally agree with the design? + Can the operations teams support it? + Can the design be evolved? + Are there other options? + Does the design comply with architectural standards and security policies? + Are any components missing (for example, code repositories, CI/CD tooling, VPC endpoints)? ## Architectural decisions As part of the design process, you will likely find more options for the overall architecture or specific parts of it. Document these options alongside the rationale for a preferred or selected option. These decisions can be documented as architectural decisions. Ensure that the main options are listed and described with enough detail for a new reader to understand the options and reasons behind a decision to use one option over another. ## Software lifecycle environments Document any changes to current environments. For example, test and development environments will be recreated in AWS and not migrated. ## Tagging Describe mandatory and recommended tagging for each infrastructure component as well as the tagging value for this design. ## Migration strategy By this point of the design, the initial assumptions about migration strategy should be validated. Confirm that there is consensus on the chosen R strategy. Document the overall application migration strategy and the strategies for individual application components. As mentioned previously, different application components might require different R types for migration. In addition, align the migration strategy to key business drivers and outcomes. Also, describe any phased approach to migration, such as the movement of components in different migration events. For more information about determining your 6 Rs, see the [AWS Migration Hub strategy recommendations](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/). ## Migration patterns and tools With a defined migration strategy for the application and infrastructure components, you can now explore specific technical patterns. For example, a rehost strategy can be implemented by migration tooling such as [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/). If you don't need to replicate the state or data, you can achieve the same outcome by redeploying the application using an Amazon Machine Image (AMI) and an application deployment pipeline. Similarly, to replatform or refactor (re-architect) an application, you can use tools such as [AWS App2Container](https://aws.amazon.com/app2container/), [AWS Database Migration Service (AWS DMS)](https://aws.amazon.com/dms/), [AWS Schema Conversion Tool](https://aws.amazon.com/dms/schema-conversion-tool/) (AWS SCT), [AWS DataSync](https://aws.amazon.com/datasync/). For containerizing, you can use [Amazon Elastic Container Service (Amazon ECS)](https://aws.amazon.com/ecs/), [Amazon Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/eks/), or [AWS Fargate](https://aws.amazon.com/fargate/). When repurchasing, you can use an AMI for a specific product or a software as a service (SaaS) solution from [AWS Marketplace](https://aws.amazon.com/marketplace/). Evaluate the different patterns and options that are available for achieving the goal. Consider pros and cons, and migration operational readiness. To help with your analysis, use the following questions: + Can migration teams support these patterns? + What is the balance between cost and benefits? + Can this application, service, or component be moved to a managed service? + What is the effort to implement this pattern? + Is there any regulation or compliance policy preventing the use of a specific pattern? + Can this pattern be reused? Reusable patterns are preferred. However, sometimes a pattern will be used only one time. Consider balance between the effort of a single-use pattern over an alternative reusable pattern. [AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/) contains a variety of migration patterns and techniques. ## Service management and operations When creating application designs for migration to AWS, consider operational readiness. When evaluating readiness requirements with your application and infrastructure teams, consider the following questions: + Are they ready to operate it? + Are incident response procedures defined? + What is the expected service level agreement (SLA)? + Is separation of duty required? + Are the different teams ready to coordinate support actions? + Who is responsible for what? ## Cutover considerations Considering the migration strategy and patterns, what is important to know at the moment the application is migrated? Cutover planning is a post-design activity. However, document any considerations for activities and requirements that can be anticipated. For example, document the requirement to perform a proof of concept, if applicable, and outline the test, audit, or validation requirements. ## Risks, assumptions, issues, and dependencies Document any open risks, assumptions, and potential issues that are not yet resolved. Assign clear ownership to these items, and track progress so that the overall design and strategy can be approved for implementation. In addition, document key dependencies for implementing this design. ## Estimating run cost To estimate the cost of your target AWS architecture, use the [AWS Pricing Calculator](https://calculator.aws/). Add your infrastructure components as defined by your design, and obtain an estimated run cost. Factor in software licenses that are required for your application components and that are not already included in the AWS services that you will use.