Domain 4: Migration and Modernization on Album69

Containers Migration General

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 4. Container migration and modernization patterns: packaging applications, choosing orchestration, and designing for production operations.

1. When Containers Fit

Containers package an application and its dependencies into an image, improving deployment consistency and portability. They are useful for applications that need controlled runtime environments, faster repeatable releases, service decomposition, or orchestration. Containerization alone does not make an application cloud-native: state, scaling, resilience, security, and operations still need design.

Databasemigration Patterns General

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 4. Database migration and modernization patterns: engine choice, conversion, replication, and cutover.

1. Start with the Outcome

Choose a database migration pattern from business and technical requirements: engine compatibility, data volume, write rate, downtime, RPO/RTO, application coupling, licensing, compliance, performance, operational skills, and cost. “Move to a managed database” is not sufficient design input.

2. Common Migration Approaches

Pattern	Fits when	Main risks
Backup/restore or native dump/load	Same-engine move or outage window is acceptable	Long downtime, large restore duration, version/extension compatibility
Snapshot/physical replication	Compatible engines/platforms and supported procedure	Engine-specific limitations, storage/network transfer, failover semantics
Full load + CDC with AWS DMS	Low-downtime data movement and supported source/target pair	Log retention, CDC lag, object conversion, transaction consistency
Schema conversion + DMS	Heterogeneous engine move	Incomplete automatic conversion, SQL/semantic differences, query performance
Logical application migration	Large redesign or different data model is justified	Dual-write consistency, longer project, cutover and reconciliation complexity

Assess engine and application dependencies
 |
Same engine? -------------------- Different engine?
 | |
native tools / DMS assess + convert schema
 | |
full load or replication full load + CDC where supported
 \ /
 validate -> controlled cutover -> observe

3. Heterogeneous Migration Checklist

Inventory schemas, indexes, constraints, views, procedures, triggers, extensions, jobs, users, encodings, collations, and application SQL.
Assess conversion coverage and manually remediate unsupported or behaviorally different objects.
Benchmark representative queries and transaction patterns against the target; data compatibility does not guarantee equivalent performance.
Select target service/class based on availability, scaling, storage, network, backup, encryption, and operational needs.
Plan endpoint changes, connection pools, DNS TTL, certificates, secrets, IAM authentication where supported, and rollback.
Test data types, null behavior, time zones, numeric precision, isolation/locking, transaction semantics, and edge cases.

4. Low-Downtime Cutover with DMS

Prepare and secure source/target endpoints and replication capacity.
Convert/apply schema using a supported assessment/conversion path.
Run full load and validate table state.
Continue CDC; monitor lag, errors, source log retention, and target apply capacity.
Exercise application against a test target and run reconciliation.
Freeze source writes or use an explicit dual-write strategy; do not improvise during cutover.
Wait for final changes to apply, validate critical invariants, switch clients, and monitor.
Retain source and rollback access until target writes and business acceptance meet the defined gate.

A low-downtime plan is not automatically zero downtime or zero data loss. Define exactly when the source stops accepting writes and how divergent writes are handled if rollback occurs.

Datasync General

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 4. DataSync is the managed, accelerated file and object transfer service for storage-to-storage movement — not server block replication, database CDC, or a backup catalog.

1. Purpose and Exam Relevance

AWS DataSync is a managed, accelerated service for transferring file and object data to, from, and between supported storage systems. Common patterns include moving on-premises NAS data to Amazon S3, EFS, or FSx; recurring replication; and moving cold data to an archival S3 storage class. DataSync handles transfer orchestration, integrity checks, encryption, scheduling, and monitoring.

Dms General

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 4. DMS moves data between supported database engines with full load and ongoing change data capture (CDC); schema and code conversion are separate concerns.

1. Purpose and Exam Relevance

AWS Database Migration Service (AWS DMS) moves data between supported database and analytics engines, including migrations into, within, or out of AWS. It supports one-time full-load migrations and ongoing change data capture (CDC) so a target can stay close to the source until cutover. DMS is central when a database must move independently from its application servers or when downtime must be minimized.

Map General

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 4. MAP is the structured migration program — assessment, mobilization, migration methodology, and conditional program support — not a data-transfer service.

1. Purpose and Exam Relevance

The AWS Migration Acceleration Program (MAP) is a structured program to help organizations assess, mobilize, migrate, and modernize workloads on AWS. It combines methodology, migration expertise, tools, and (for eligible engagements) financial incentives or credits subject to current program terms. MAP is not a data-transfer service and does not replace architecture, migration execution, or operational ownership.

Mgn General

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 4. MGN is the server rehosting service: continuous block-level replication of source servers to a staging area in the target Region, then EC2 test and cutover launches.

AWS documentation currently refers to Application Migration Service as AWS Transform MGN (often shortened to MGN). Product names and supported source/target configurations can change; confirm them in the linked guide before implementation.

1. Purpose and Exam Relevance

MGN is a rehosting service for moving physical, virtual, and cloud servers to Amazon EC2 with limited application changes. It continuously replicates source-server block storage to a staging area in the target Region, then launches converted EC2 test and cutover instances. It is useful when the priority is to move server workloads quickly and defer redesign.

Microservices Patterns General

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 4. Microservices modernization patterns: decomposition, strangler migration, service boundaries, and data ownership.

1. When Microservices Fit

Microservices can help when independently deployable business capabilities need separate scaling, release cadence, fault boundaries, or team ownership. They are not a default upgrade for every monolith. A well-structured monolith may be cheaper and simpler when the domain is cohesive, scaling needs are shared, or teams cannot support distributed operations.

2. Decomposition and Migration

Legacy monolith AWS target
+----------------------+ +----------------------------+
| Orders | Billing | | | API Gateway / ALB |
| Catalog | Shipping | ----->| Order service -> own data |
+----------------------+ | Billing service -> own data |
 shared DB | Events / queues between |
 | bounded contexts |
 +----------------------------+

Decompose around business capabilities and bounded contexts, not technical layers or arbitrary table boundaries.
Use the strangler pattern: place a routing layer in front of the legacy system, move one capability at a time, and route selected calls to the new service.
Establish clear service ownership, APIs/events, data contracts, SLOs, and rollback behavior before broad decomposition.
Avoid a distributed monolith: services that must deploy together, share a schema, and synchronously call each other across every request have moved complexity without gaining independence.

3. Communication and Data Patterns

Need	Pattern	Trade-off
Immediate query/command response	Synchronous API (API Gateway, ALB, service endpoint)	Simpler caller flow, but latency and availability are coupled
Loose coupling and burst absorption	SQS queue	Durable buffer and retry; adds eventual consistency and queue operations
Publish domain events to multiple subscribers	EventBridge or SNS	Fan-out and routing; consumers must be idempotent and tolerate reordering/duplicates where applicable
Multi-step business workflow	Step Functions or application saga	Explicit state/retry/compensation; workflow design becomes a first-class concern
Atomic database update plus event publication	Transactional outbox/CDC pattern	Avoids dual-write loss; adds outbox processing and deduplication

Prefer data ownership per service. Cross-service joins and shared writable databases couple release and failure domains. Replicate read models or compose APIs for cross-domain views; define consistency and staleness expectations explicitly.

Migrationhub General

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 4. Migration Hub is the planning and tracking layer for migration portfolios — application inventory, waves, and status. It does not replicate servers, databases, or files.

1. Purpose and Exam Relevance

AWS Migration Hub provides a place to discover/organize migration information and track application migration progress across supported AWS and partner tools. It helps teams group servers into applications, coordinate waves, and report status across a portfolio. It is a planning and tracking layer, not the data plane that copies servers, databases, or files.

Serverless Migration General

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 4. Serverless migration and modernization patterns: event-driven decomposition, service selection, and design constraints.

1. When Serverless Fits

Serverless architectures are useful when teams want managed scaling and reduced infrastructure operations for event-driven, variable, or independently deployable workloads. AWS services such as Lambda, API Gateway, EventBridge, SQS, SNS, Step Functions, and managed data stores can form the target. Serverless is not automatically cheaper, and it does not remove security, reliability, integration, or capacity planning.

Snowfamily General

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 4. Snow Family covers the offline-transfer decision — physical shipment versus network transfer — and the operational, security, and chain-of-custody controls it requires.

Availability caveat: AWS documentation states that Snowball Edge is no longer available to new customers. Existing eligible customers should follow current service guidance. For new projects, validate current regional options such as AWS Data Transfer Terminal or AWS Partner solutions; do not assume a Snow device can be ordered.

Transferfamily General

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 4. Transfer Family provides managed file-transfer protocols and interfaces (SFTP, FTPS, FTP, AS2, web apps) backed by S3/EFS — partner-facing workflows, not bulk NAS migration.

1. Purpose and Exam Relevance

AWS Transfer Family provides managed endpoints and interfaces for moving files into and out of AWS storage while preserving familiar file-transfer workflows. It supports SFTP, FTPS, FTP, AS2, and browser-based experiences for supported use cases, with Amazon S3 and Amazon EFS as storage backends. Use it when employees, customers, or business partners need a managed protocol-compatible interface; it is not a bulk NAS migration engine.