AWS Prescriptive Guidance

Containerizing and migrating Java

applications using AWS App2Container
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container

AWS Prescriptive Guidance: Containerizing and migrating Java

applications using AWS App2Container
Copyright © 2023 Amazon Web Services, Inc. and/or its affiliates. All rights reserved.

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not
Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or
discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may
or may not be affiliated with, connected to, or sponsored by Amazon.
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container

Table of Contents
Introduction ...................................................................................................................................... 1
Targeted business outcomes ........................................................................................................ 1
Assessment ....................................................................................................................................... 2
Prerequisites ...................................................................................................................................... 4
Containerize and migrate .................................................................................................................... 5
Solution architecture .................................................................................................................. 5
Configuration ..................................................................................................................................... 7
Automation ....................................................................................................................................... 8
Automation using Ansible ........................................................................................................... 8
Automation using Jenkins ........................................................................................................... 8
Resources .......................................................................................................................................... 9
AWS services ............................................................................................................................. 9
References ................................................................................................................................. 9
Patterns .................................................................................................................................... 9
Document history ............................................................................................................................. 10
Glossary .......................................................................................................................................... 11
Migration terms ....................................................................................................................... 11
Modernization terms ................................................................................................................. 16

iii
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container
Targeted business outcomes

Containerizing and migrating

Java applications using AWS
App2Container
Durga Prasad Cheepuri, Atul Langote, Dhananjay Karanjkar, Raja Koppuravuri, Saurabh Singh, and Varun
Sharma, Amazon Web Services (AWS)

March 2022 (document history (p. 10))

Containerizing applications on Amazon Web Services (AWS) is a way to modernize Java applications,
providing portability between platforms, efficient resource utilization, scalability, agility, and faster
delivery of enhancements. Containerizing applications also, reduces operational overhead and
infrastructure costs, increases development and deployment agility, and standardizes build and
deployment operations across the organization.

AWS App2Container (A2C) is a command line tool to help lift and shift applications running in on-
premises data centers or on virtual machines. Applications can then run in containers that are managed
by Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), or
AWS App Runner.

App2Container can identify and create an inventory for application servers running ASP.NET (Windows)
and Java applications (Linux) that are candidates for containerization. You can use App2Container to
generate container images for one or more applications running on Windows or Linux servers that are
compatible with the Open Containers Initiative (OCI), including commercial off-the-shelf applications
(COTs). App2Container does not need the source code of the application to containerize it.

This guide focuses on the aspects that an organization should consider when choosing containerization
as an approach and using AWS App2Container to modernize Java applications. This guide can help
technical teams to identify the types of applications that make good candidates for containerization
for quicker modernization. It also covers prerequisites to take care before containerization and different
ways to use App2Container to accommodate any hardware, software, or network restrictions for using
the tool on the application server.

Targeted business outcomes

Using AWS App2Container to modernize Java applications and run them as containers hosted on
Amazon ECS, Amazon EKS, or AWS App Runner provides the following useful business outcomes:

• It’s more efficient and quicker to release enhancements to containerized applications.

• Using the automatic scaling features provided by the AWS environment on Amazon ECS or Amazon
EKS, the application can quickly respond to heavier traffic.
• Because the containerized application is a standard Docker image, it’s portable for any platform that
can host a Docker image, making migration to other platforms more efficient.

1
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container

Assessment
Assessment of applications for containerization helps uncover all the dependencies and risks. Assessment
also helps sort applications into priority buckets for modernization and migration.

During the assessment phase, focus on the following key areas:

• Operating system dependencies for containerization – Automated containerization tools such as

AWS App2Container have some limitations on the application frameworks and operating systems
for containerization. For more information about the supported applications, see the App2Container
documentation.
• Regulatory compliance – It’s efficient to ensure containerized applications are compliant with all the
regulations before they are deployed on the target environment, instead of acting in a reactive way
after deployment and mitigating then. Check for vulnerabilities in the images, unauthorized inter-
container communication, access controls to containers and data, and automated scans to prevent
malicious activity.
• Disaster recovery (DR) solution – Each application has its own specific service level agreement
(SLA) for downtime. Keep in mind the application’s recovery point objective (RPO) and recovery time
objective (RTO) when planning the distribution of the container clusters. App2Container by default
deploys the application to multiple Availability Zones.
• Data storage – Containers are best used as stateless. For stateful containers, the data must be stored
external to the container. If a container goes out of service, you can spin up a new one using the image
and the external volume attached with no data loss.
• Configuration and secrets management – The target environment’s parameter store or the secret
store can be used to store and retrieve from configuration and secrets from the container. It’s vital to
ensure that the secrets are accessible to the relevant container only. All operations on configuration
and secrets should be logged. The communication channel between the container and the secret store
must be secure.
• Logs management – For auditing, the logs generated by each container will be shipped to a log
management service that resides external to the container. Because an application consists of multiple
services and processes, each residing in different containers, the logs from each container should have
a unique ID.
• Build and deployment process – Most enterprises have some sort of build and deployment process to
release their applications and features. To take advantage of containerization, building and deploying
the applications should be automated using a CI/CD pipeline. A pipeline brings advantages such
as one-click infrastructure provisioning and decommissioning, faster and error-proof deployments,
automation, and reduced time to release new features.
• Upstream and downstream applications – It’s a good practice to containerize and migrate all
dependent applications in batches. In scenarios where that is not feasible, communication channels
from the containerized application to the upstream and downstream applications should be securely
opened. Ensure that the bandwidth supported by this channel doesn’t disrupt the application
functionality.
• License dependencies – Multiple instances of an application run within containers, which can become
costly. Check the contracts and eligibility to deploy software on containers. Understand what tools are
used for metering the software consumed on containers.
• Containerization possibility on application servers or worker machines – The containerization
process consumes additional resources on the server, such as the disk space, computational power
and memory. The application server must be analyzed to ensure that it is capable of supporting the
containerization process. Otherwise, you can use a worker machine that has the required resources and
can communicate with the application server.
• Developer skills and production support on containers – The current application team should upskill
themselves on the containerization technology. The team should be able to troubleshoot issues in

2
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container

the process, tweak the configurations if needed and be able to support the applications deployed on
containers.

You can use App2Container to containerize Java applications running on Linux, such as standalone JBoss,
Apache Tomcat, IBM WebSphere, Oracle WebLogic. You can also use App2Container to containerize
generic Java applications such as Spring Boot. Application containerization works with microservices
and distributed applications. Though all Java applications can be modernized using App2Container, the
following criteria can help you choose the right applications to modernize for quicker migrations:

• Applications that are packaged as a single binary are easier to containerize. Additionally, Java
applications can be containerized with a Java Runtime Environment (JRE). Each container can use the
specific JRE that it needs.
• Stateless applications are a good choice for modernizing into containers. These applications store
minimal information locally and store most of their data on a persistent data store.
• Applications that are being released using a continuous integration and continuous deployment
(CI/CD) pipeline are good candidates for containerization. Containerize each application and bring
in a container orchestration platform such as Amazon ECS or Amazon EKS, which is taken care
automatically by App2Container.

Most enterprise applications are integrated with various other services for authentication, persistent data
store, caching, asynchronous communication, logging, and notifications. The containerized application
should be tested on premises with all existing integration points to facilitate containerization success.
When ready to migrate to AWS, all appropriate integration points and data storage must be migrated to
AWS. Any necessary updates must be made to the configuration before the application container can be
deployed on AWS.

Data stored in file systems can be migrated to AWS using various tools that cater to the use case. Data
stored in a cache such as Redis can be migrated to Amazon ElastiCache. Data stored in databases can be
migrated by using the database’s own native tools or by using AWS Database Migration Service (AWS
DMS). AWS DMS also provides the change data capture (CDC) option to replicate ongoing changes from a
source data store until cutover.

AWS provides its own monitoring and operational data logging and visualizing service called Amazon
CloudWatch. A CloudWatch agent can be packed into the container along with the application to use this
service.

For organizations where source code is not available or not maintainable, App2Container is a great fit for
containerization because it operates on the application’s runtime environment and doesn’t require the
source code.

3
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container

Prerequisites and setup

There are prerequisites for setting up and using AWS App2Container (A2C). In most cases, applications
are running in a private network. It might not be possible for the application server to meet the
requirements to containerize your application and deploy to AWS or to install the Docker engine on the
application server. In such cases, a consolidated virtual machine (VM) can be provisioned and used as a
platform to containerize the applications running on the application servers. Choose a worker machine
that can be used for modernizing multiple applications and application servers. The worker machine
should meet the following requirements:

• Must have internet connectivity or alternate connection with access to necessary AWS services.
• Have connectivity to the application servers to copy the tar package from the application server by
using Secure Copy Protocol (SCP) or Secure Shell (SSH). For the connection, allow access to port 22
from the worker machine.
• Docker must be installed only on the worker machine.

For scenarios where the application server can only be accessed remotely, a worker machine can
use the remote option to run all the App2Container tasks. Running remotely requires the following
configuration:

• SSH connectivity from the worker machine to the application server

• SSH credentials of the application server stored in AWS Secrets Manager and configured on the worker
machine

For scenarios where there is no direct connection between the application server and the worker
machine, you must use a bridge machine. The bridge machine can connect to the application server and
the worker machine. The bridge machine transfers artifacts from the application server to the worker
machine.

4
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container
Solution architecture

Containerize and migrate

If the application server meets all the prerequisites and can run all the AWS App2Container (A2C) tasks,
follow the instructions in the App2Container documentation.

If the application server can’t run all the App2Container tasks, use a worker machine. Split the
App2Container tasks between the application server and the worker machine.

On the application server, you install and initialize App2Container. Then you analyze the Java
applications that are running on the application server. The analysis generates the analysis.json file.
Then generate the archive and upload it to an Amazon Simple Storage Service (Amazon S3) bucket or
manually copy the archive to the worker machine.

On the worker machine, containerize the application to generate a Docker image. Based on the
application type, App2Container takes a conservative approach, known as process mode, to identify
dependencies. In process mode, all nonsystem files on the application server are included in the
container image. In such cases, it is possible that a large image is generated. Then deploy the application
to Amazon ECS or Amazon EKS. During containerization, a deployment.json file is created, which is then
used by the generate-app-deployment command.

For more information on splitting the tasks between the application server and a worker machine, see
the App2Container documentation.

If the application server can only be accessed remotely, run App2Container tasks from a worker machine
using remote commands. For more information, see the Migrate on-premises Java applications to AWS
using AWS App2Container pattern.

Solution architecture
The following diagram shows the process and an example architecture for containerizing Java
applications using App2Container:

1. On the application servers, set up prerequisites, install App2Container, discover applications, and
extract applications.
2. On the worker machine, set up prerequisites, install App2Container, copy extracted applications to
the worker machine, containerize, generate deployment, deploy the AWS CloudFormation template
and the CI/CD pipeline.
3. App2Container uploads the image to Amazon Elastic Container Registry (Amazon ECR), provisions
Amazon ECS, and provisions the pipeline.
4. AWS CodePipeline pulls the code from AWS CodeCommit.
5. CodePipeline pushes the code to AWS CodeBuild.
6. The CI/CD pipeline pushes the Docker images to Amazon ECR.

5
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container
Solution architecture

6
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container

Configuration
AWS App2Container (A2C) tasks generate the analysis.json and deployment.json files. These files
have configurable values to control what comprises the generated Docker image and the specifications
of the target environment on AWS.

Provide values for the following parameters supported by analysis.json:

• appExcludedFiles – The list of files that should be excluded from the container image.
• appSpecificFiles – The application-specific files that should be included within the container
image.
• applicationMode (Boolean, required) – The approach that App2Container uses to determine which
files to include in your container image. App2Container uses application mode (value=true) for
supported application frameworks, and process mode (value=false) for all other configurations. You
can override this value if necessary. For example, if your application runs on a supported framework,
but App2Container does not recognize it and assigns process mode, you can override the setting to use
application mode instead.
• imageRepository – The location where the container image is stored.
• logLocations – Specific log files or log directories to be routed to stdout.

Be careful when specifying paths in the including and excluding parameters, because the paths have
a direct impact on how the application runs after deployment. For example, if you exclude certain
application-dependent files, the application might not start or run successfully. Similarly, including
non-dependent files in the container build might unnecessarily increase the container size.

For the complete list of parameters supported by analysis.json, see the App2Container
documentation.

The deployment.json file generated by the containerize task provides configurable values to choose
the target environment on AWS.

• Don’t change the a2CTemplateVersion, applicationId, and imageName values.

• Choose the target deployment environment of Amazon ECS or Amazon EKS or AWS App Runner by
setting createEcsArtifacts or createEksArtifacts or createAppRunnerArtifacts to true.
• Configure the reuseResources object. Include shared resources, such as vpcId, sshKeyPairName,
and acmCertificateName, that you can re-use across the AWS CloudFormation template.

For the compete list of parameters supported by deployment.json, see the App2Container
documentation.

When App2Container runs in process mode, the container image generated can be huge, because it
includes most of the folders running on the application server. For a detailed approach on reducing the
size of the Docker image generated by App2Container, use the Optimize AWS App2Container generated
Docker images pattern. The optimized Docker image can then be further used in the next App2Container
command.

7
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container
Automation using Ansible

Automation
When migrating multiple servers, using the command line to run the AWS App2Container workflow is
not a scalable solution. For example, manually managing and tracking the progress of each workflow can
become overwhelming. The migration can be further complicated if the application server doesn’t have
internet access or sufficient hardware resources, or if the Docker engine can’t be installed. If you manage
servers by using Red Hat Ansible or Jenkins, you can use that tool to orchestrate the App2Container
workflow.

Automation using Ansible

Ansible Playbook automates serial performance of tasks, monitoring migration progress for each
application, which reduces human intervention and eventually speeds up migration. The playbook can
be run from the worker machine or a proxy instance that can communicate with both the application
server and the worker machine. The playbook can containerize multiple application servers in parallel.
For more insight on how Ansible can be used to automate the App2Container end to end workflow, see
the Automate AWS App2Container workflow using Ansible blog post.

Automation using Jenkins

Using Jenkins, you can centralize control and manage modernization of multiple application servers.
You can use the Jenkins user interface to visualize the App2Container workflow. Jenkins facilitates the
integration of the existing continuous integration pipeline of the application to one that is created by
App2Container.

8
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container
AWS services

Resources
AWS services
• AWS App2Container
• AWS App Runner
• Amazon CloudWatch
• Amazon Elastic Container Registry
• Amazon Elastic Container Service
• Amazon Elastic Kubernetes Service
• AWS Database Migration Service

References
• Cloud Data Migration
• app2container generate app-deployment command
• Applications you can containerize using AWS App2Container
• Configuring application containers
• Configuring container deployment
• Containerizing a Java application on Linux
• Setting up App2Container
• Seeding a new Redis cluster with an externally created backup
• Automate AWS App2Container workflow using Ansible (blog post)

Patterns
• Migrate on-premises Java applications to AWS using AWS App2Container (pattern)
• Optimize AWS App2Container generated Docker images (pattern)

9
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container

Document history
The following table describes significant changes to this guide. If you want to be notified about future
updates, you can subscribe to an RSS feed.

Change Description Date

Initial publication (p. 10) — March 30, 2022

10
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container
Migration terms

AWS Prescriptive Guidance glossary

The following are commonly used terms in strategies, guides, and patterns provided by AWS Prescriptive
Guidance. To suggest entries, please use the Provide feedback link at the end of the glossary.

Migration terms
7 Rs

Seven common migration strategies for moving applications to the cloud. These strategies build
upon the 5 Rs that Gartner identified in 2011 and consist of the following:
• Refactor/re-architect – Move an application and modify its architecture by taking full advantage
of cloud-native features to improve agility, performance, and scalability. This typically involves
porting the operating system and database. Example: Migrate your on-premises Oracle database
to the Amazon Aurora PostgreSQL-Compatible Edition.
• Replatform (lift and reshape) – Move an application to the cloud, and introduce some level of
optimization to take advantage of cloud capabilities. Example: Migrate your on-premises Oracle
database to Amazon Relational Database Service (Amazon RDS) for Oracle in the AWS Cloud.
• Repurchase (drop and shop) – Switch to a different product, typically by moving from a traditional
license to a SaaS model. Example: Migrate your customer relationship management (CRM) system
to Salesforce.com.
• Rehost (lift and shift) – Move an application to the cloud without making any changes to take
advantage of cloud capabilities. Example: Migrate your on-premises Oracle database to Oracle on
an EC2 instance in the AWS Cloud.
• Relocate (hypervisor-level lift and shift) – Move infrastructure to the cloud without purchasing
new hardware, rewriting applications, or modifying your existing operations. This migration
scenario is specific to VMware Cloud on AWS, which supports virtual machine (VM) compatibility
and workload portability between your on-premises environment and AWS. You can use the
VMware Cloud Foundation technologies from your on-premises data centers when you migrate
your infrastructure to VMware Cloud on AWS. Example: Relocate the hypervisor hosting your
Oracle database to VMware Cloud on AWS.
• Retain (revisit) – Keep applications in your source environment. These might include applications
that require major refactoring, and you want to postpone that work until a later time, and legacy
applications that you want to retain, because there’s no business justification for migrating them.
• Retire – Decommission or remove applications that are no longer needed in your source
environment.
active-active migration

A database migration method in which the source and target databases are kept in sync (by using
a bidirectional replication tool or dual write operations), and both databases handle transactions
from connecting applications during migration. This method supports migration in small, controlled
batches instead of requiring a one-time cutover. It’s more flexible but requires more work than
active-passive migration (p. 11).
active-passive migration

A database migration method in which in which the source and target databases are kept in sync,
but only the source database handles transactions from connecting applications while data is
replicated to the target database. The target database doesn’t accept any transactions during
migration.

11
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container
Migration terms

application portfolio

A collection of detailed information about each application used by an organization, including the
cost to build and maintain the application, and its business value. This information is key to the
portfolio discovery and analysis process and helps identify and prioritize the applications to be
migrated, modernized, and optimized.
artificial intelligence operations (AIOps)

The process of using machine learning techniques to solve operational problems, reduce operational
incidents and human intervention, and increase service quality. For more information about how
AIOps is used in the AWS migration strategy, see the operations integration guide.
AWS Cloud Adoption Framework (AWS CAF)

A framework of guidelines and best practices from AWS to help organizations develop an efficient
and effective plan to move successfully to the cloud. AWS CAF organizes guidance into six focus
areas called perspectives: business, people, governance, platform, security, and operations. The
business, people, and governance perspectives focus on business skills and processes; the platform,
security, and operations perspectives focus on technical skills and processes. For example, the
people perspective targets stakeholders who handle human resources (HR), staffing functions, and
people management. For this perspective, AWS CAF provides guidance for people development,
training, and communications to help ready the organization for successful cloud adoption. For more
information, see the AWS CAF website and the AWS CAF whitepaper.
AWS Workload Qualification Framework (AWS WQF)

A tool that evaluates database migration workloads, recommends migration strategies, and
provides work estimates. AWS WQF is included with AWS Schema Conversion Tool (AWS SCT). It
analyzes database schemas and code objects, application code, dependencies, and performance
characteristics, and provides assessment reports.
business continuity planning (BCP)

A plan that addresses the potential impact of a disruptive event, such as a large-scale migration, on
operations and enables a business to resume operations quickly.
change data capture (CDC)

The process of tracking changes to a data source, such as a database table, and recording metadata
about the change. You can use CDC for various purposes, such as auditing or replicating changes in a
target system to maintain synchronization.
Cloud Center of Excellence (CCoE)

A multi-disciplinary team that drives cloud adoption efforts across an organization, including
developing cloud best practices, mobilizing resources, establishing migration timelines, and leading
the organization through large-scale transformations. For more information, see the CCoE posts on
the AWS Cloud Enterprise Strategy Blog.
cloud stages of adoption

The four phases that organizations typically go through when they migrate to the AWS Cloud:
• Project – Running a few cloud-related projects for proof of concept and learning purposes
• Foundation – Making foundational investments to scale your cloud adoption (e.g., creating a
landing zone, defining a CCoE, establishing an operations model)
• Migration – Migrating individual applications
• Re-invention – Optimizing products and services, and innovating in the cloud

These stages were defined by Stephen Orban in the blog post The Journey Toward Cloud-First &
the Stages of Adoption on the AWS Cloud Enterprise Strategy blog. For information about how they
relate to the AWS migration strategy, see the migration readiness guide.

12
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container
Migration terms

configuration management database (CMDB)

A repository that stores and manages information about a database and its IT environment,
including both hardware and software components and their configurations. You typically use data
from a CMDB in the portfolio discovery and analysis stage of migration.
epic

In agile methodologies, functional categories that help organize and prioritize your work. Epics
provide a high-level description of requirements and implementation tasks. For example, AWS CAF
security epics include identity and access management, detective controls, infrastructure security,
data protection, and incident response. For more information about epics in the AWS migration
strategy, see the program implementation guide.
flash-cut migration

A database migration method that uses continuous data replication through change data capture
(CDC) (p. 12) to migrate data in the shortest time possible, instead of using a phased approach.
The objective is to keep downtime to a minimum.
heterogeneous database migration

Migrating your source database to a target database that uses a different database engine (for
example, Oracle to Amazon Aurora). Heterogeneous migration is typically part of a re-architecting
effort, and converting the schema can be a complex task. AWS provides AWS SCT that helps with
schema conversions.
homogeneous database migration

Migrating your source database to a target database that shares the same database engine (for
example, Microsoft SQL Server to Amazon RDS for SQL Server). Homogeneous migration is typically
part of a rehosting or replatforming effort. You can use native database utilities to migrate the
schema.
hypercare period

Immediately following cutover, the period of time when a migration team manages and monitors
the migrated applications in the cloud in order to address any issues. Typically, this period is
1–4 days in length. At the end of the hypercare period, the migration team typically transfers
responsibility for the applications to the cloud operations team.
idle application

An application that has an average CPU and memory usage between 5 and 20 percent over a
period of 90 days. In a migration project, it is common to retire these applications or retain them on
premises.
incremental migration

A cutover strategy in which you migrate your application in small parts instead of performing a
single, full cutover. For example, you might move only a few microservices or users to the new
system initially. After you verify that everything is working properly, you can incrementally move
additional microservices or users until you can decommission your legacy system. This strategy
reduces the risks associated with large migrations.
IT information library (ITIL)

A set of best practices for delivering IT services and aligning these services with business
requirements. ITIL provides the foundation for ITSM.
IT service management (ITSM)

Activities associated with designing, implementing, managing, and supporting IT services for an
organization. For information about integrating cloud operations with ITSM tools, see the operations
integration guide.

13
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container
Migration terms

landing zone

A landing zone is a well-architected, multi-account AWS environment that is scalable and secure.
This is a starting point from which your organizations can quickly launch and deploy workloads and
applications with confidence in their security and infrastructure environment. For more information
about landing zones, see Setting up a secure and scalable multi-account AWS environment.
large migration

A migration of 300 or more servers.

Migration Acceleration Program (MAP)

An AWS program that provides consulting support, training, and services to help organizations
build a strong operational foundation for moving to the cloud, and to help offset the initial cost of
migrations. MAP includes a migration methodology for executing legacy migrations in a methodical
way and a set of tools to automate and accelerate common migration scenarios.
Migration Portfolio Assessment (MPA)

An online tool that provides information for validating the business case for migrating to the AWS
Cloud. MPA provides detailed portfolio assessment (server right-sizing, pricing, TCO comparisons,
migration cost analysis) as well as migration planning (application data analysis and data collection,
application grouping, migration prioritization, and wave planning). The MPA tool (requires login) is
available free of charge to all AWS consultants and APN Partner consultants.
Migration Readiness Assessment (MRA)

The process of gaining insights about an organization’s cloud readiness status, identifying strengths
and weaknesses, and building an action plan to close identified gaps, using the AWS CAF. For
more information, see the migration readiness guide. MRA is the first phase of the AWS migration
strategy.
migration at scale

The process of moving the majority of the application portfolio to the cloud in waves, with more
applications moved at a faster rate in each wave. This phase uses the best practices and lessons
learned from the earlier phases to implement a migration factory of teams, tools, and processes to
streamline the migration of workloads through automation and agile delivery. This is the third phase
of the AWS migration strategy.
migration factory

Cross-functional teams that streamline the migration of workloads through automated, agile
approaches. Migration factory teams typically include operations, business analysts and owners,
migration engineers, developers, and DevOps professionals working in sprints. Between 20 and 50
percent of an enterprise application portfolio consists of repeated patterns that can be optimized by
a factory approach. For more information, see the discussion of migration factories and the Cloud
Migration Factory guide in this content set.
migration metadata

The information about the application and server that is needed to complete the migration. Each
migration pattern requires a different set of migration metadata. Examples of migration metadata
include the target subnet, security group, and AWS account.
migration pattern

A repeatable migration task that details the migration strategy, the migration destination, and
the migration application or service used. Example: Rehost migration to Amazon EC2 with AWS
Application Migration Service.
migration strategy

The approach used to migrate a workload to the AWS Cloud. For more information, see the 7
Rs (p. 11) entry in this glossary and see Mobilize your organization to accelerate large-scale
migrations.

14
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container
Migration terms

offline migration

A migration method in which the source workload is taken down during the migration process. This
method involves extended downtime and is typically used for small, non-critical workloads.
online migration

A migration method in which the source workload is copied to the target system without being
taken offline. Applications that are connected to the workload can continue to function during
the migration. This method involves zero to minimal downtime and is typically used for critical
production workloads.
operational-level agreement (OLA)

An agreement that clarifies what functional IT groups promise to deliver to each other, to support a
service-level agreement (SLA).
operations integration (OI)

The process of modernizing operations in the cloud, which involves readiness planning, automation,
and integration. For more information, see the operations integration guide.
organizational change management (OCM)

A framework for managing major, disruptive business transformations from a people, culture, and
leadership perspective. OCM helps organizations prepare for, and transition to, new systems and
strategies by accelerating change adoption, addressing transitional issues, and driving cultural and
organizational changes. In the AWS migration strategy, this framework is called people acceleration,
because of the speed of change required in cloud adoption projects. For more information, see the
OCM guide.
playbook

A set of predefined steps that capture the work associated with migrations, such as delivering core
operations functions in the cloud. A playbook can take the form of scripts, automated runbooks, or a
summary of processes or steps required to operate your modernized environment.
portfolio assessment

A process of discovering, analyzing, and prioritizing the application portfolio in order to plan the
migration. For more information, see Evaluating migration readiness.
responsible, accountable, consulted, informed (RACI) matrix

A matrix that defines and assigns roles and responsibilities in a project. For example, you can create
a RACI to define security control ownership or to identify roles and responsibilities for specific tasks
in a migration project.
runbook

A set of manual or automated procedures required to perform a specific task. These are typically
built to streamline repetitive operations or procedures with high error rates.
service-level agreement (SLA)

An agreement that clarifies what an IT team promises to deliver to their customers, such as service
uptime and performance.
task list

A tool that is used to track progress through a runbook. A task list contains an overview of the
runbook and a list of general tasks to be completed. For each general task, it includes the estimated
amount of time required, the owner, and the progress.
workstream

Functional groups in a migration project that are responsible for a specific set of tasks. Each
workstream is independent but supports the other workstreams in the project. For example, the

15
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container
Modernization terms

portfolio workstream is responsible for prioritizing applications, wave planning, and collecting
migration metadata. The portfolio workstream delivers these assets to the migration workstream,
which then migrates the servers and applications.
zombie application

An application that has an average CPU and memory usage below 5 percent. In a migration project,
it is common to retire these applications.

Modernization terms
anti-pattern

A frequently used solution for a recurring issue where the solution is counter-productive, ineffective,
or less effective than an alternative.
business capability

What a business does to generate value (for example, sales, customer service, or marketing).
Microservices architectures and development decisions can be driven by business capabilities.
For more information, see the Organized around business capabilities section of the Running
containerized microservices on AWS whitepaper.
domain-driven design

An approach to developing a complex software system by connecting its components to evolving

domains, or core business goals, that each component serves. This concept was introduced by Eric
Evans in his book, Domain-Driven Design: Tackling Complexity in the Heart of Software (Boston:
Addison-Wesley Professional, 2003). For information about how you can use domain-driven design
with the strangler fig pattern, see Modernizing legacy Microsoft ASP.NET (ASMX) web services
incrementally by using containers and Amazon API Gateway.
historian modernization

An approach used to modernize and upgrade operational technology (OT) systems to better serve
the needs of the manufacturing industry. A historian is a type of database that is used to collect and
store data from various sources in a factory.
microservice

A small, independent service that communicates over well-defined APIs and is typically owned by
small, self-contained teams. For example, an insurance system might include microservices that map
to business capabilities, such as sales or marketing, or subdomains, such as purchasing, claims, or
analytics. The benefits of microservices include agility, flexible scaling, easy deployment, reusable
code, and resilience. For more information, see Integrating microservices by using AWS serverless
services.
microservices architecture

An approach to building an application with independent components that run each application
process as a microservice. These microservices communicate through a well-defined interface by
using lightweight APIs. Each microservice in this architecture can be updated, deployed, and scaled
to meet demand for specific functions of an application. For more information, see Implementing
microservices on AWS.
modernization

Transforming an outdated (legacy or monolithic) application and its infrastructure into an agile,
elastic, and highly available system in the cloud to reduce costs, gain efficiencies, and take
advantage of innovations. For more information, see Strategy for modernizing applications in the
AWS Cloud.

16
 AWS Prescriptive Guidance Containerizing and
migrating Java applications using AWS App2Container
Modernization terms

modernization readiness assessment

An evaluation that helps determine the modernization readiness of an organization’s applications;

identifies benefits, risks, and dependencies; and determines how well the organization can support
the future state of those applications. The outcome of the assessment is a blueprint of the target
architecture, a roadmap that details development phases and milestones for the modernization
process, and an action plan for addressing identified gaps. For more information, see Evaluating
modernization readiness for applications in the AWS Cloud.
monolithic applications (monoliths)

Applications that run as a single service with tightly coupled processes. Monolithic applications have
several drawbacks. If one application feature experiences a spike in demand, the entire architecture
must be scaled. Adding or improving a monolithic application’s features also becomes more complex
when the code base grows. To address these issues, you can use a microservices architecture. For
more information, see Decomposing monoliths into microservices.
polyglot persistence

Independently choosing a microservice’s data storage technology based on data access patterns
and other requirements. If your microservices have the same data storage technology, they can
encounter implementation challenges or experience poor performance. Microservices are more
easily implemented and achieve better performance and scalability if they use the data store best
adapted to their requirements. For more information, see Enabling data persistence in microservices.
split-and-seed model

A pattern for scaling and accelerating modernization projects. As new features and product
releases are defined, the core team splits up to create new product teams. This helps scale your
organization’s capabilities and services, improves developer productivity, and supports rapid
innovation. For more information, see Phased approach to modernizing applications in the AWS
Cloud.
strangler fig pattern

An approach to modernizing monolithic systems by incrementally rewriting and replacing system

functionality until the legacy system can be decommissioned. This pattern uses the analogy of a fig
vine that grows into an established tree and eventually overcomes and replaces its host. The pattern
was introduced by Martin Fowler as a way to manage risk when rewriting monolithic systems. For
an example of how to apply this pattern, see Modernizing legacy Microsoft ASP.NET (ASMX) web
services incrementally by using containers and Amazon API Gateway.
two-pizza team

A small DevOps team that you can feed with two pizzas. A two-pizza team size ensures the best
possible opportunity for collaboration in software development. For more information, see the Two-
pizza team section of the Introduction to DevOps on AWS whitepaper.

17