Migration & Modernization

Assumes you're comfortable with VPC networking (Part 4), database fundamentals and DMS (Part 6), and the 6 R's as briefly introduced in Part 12 — this part goes into the actual depth SAP-C02 expects, since "Accelerate Workload Migration and Modernization" is 20% of that exam, its single heaviest-weighted domain.

Table of Contents#

1. Why This Part Exists
2. The 6 R's, in Real Depth
3. Choosing a Migration Strategy Per Application
4. Application Discovery Service — Knowing What You Actually Have
5. The Agentless Collector
6. Migration Hub — The Central Tracking Surface
7. AWS Transform — Agentic Migration and Modernization
8. AWS Transform MGN — Rehosting, Revisited
9. How MGN Actually Works: Continuous Replication and Cutover
10. Wave Planning
11. Database Migration Service, Revisited for Heterogeneous Migrations
12. The Schema Conversion Tool
13. Moving Data at Scale: The Decision Framework
14. AWS DataSync — Online, Automated Data Transfer
15. DataSync Enhanced Mode for Cross-Cloud Transfers
16. AWS Transfer Family — Managed File Transfer
17. The Snow Family, and Its 2026 Reality
18. AWS Data Transfer Terminal
19. Choosing a Physical vs Network Transfer Path
20. Network Foundations for a Migration
21. Modernization Beyond Rehosting: Refactor Patterns
22. Mainframe and VMware Modernization
23. Cutover Strategies and Minimizing Downtime
24. Rollback Planning — The Step Migrations Skip
25. Cost During and After Migration
26. Security During Migration
27. A Full Worked Example: Migrating a Three-Tier Application
28. Migration Best Practices — The Consolidated Checklist
29. Part 17 CLI Cheat Sheet
30. Common Mistakes and Interview Traps
31. Worked Practice Problems
32. Summary and What's Next

---

Why This Part Exists#

Part 12 introduced the 6 R's and Migration Hub at a survey level, appropriate for a capstone chapter covering many topics briefly. This part is where migration gets the depth its actual exam weight deserves: Application Discovery Service and the Agentless Collector for knowing what's actually being migrated, AWS Transform (2026's rebranded, agentic migration platform) and its MGN rehosting engine for actually moving compute, and a full, currency-checked treatment of the data-movement services — including two genuinely important 2026 changes worth knowing specifically: the Snow Family closing to new customers, and Application Migration Service's rebrand to AWS Transform MGN.

The 6 R's, in Real Depth#

Choosing a Migration Strategy Per Application#

The single most common exam and real-world mistake: applying one strategy uniformly across an entire portfolio. A real migration portfolio is a mix, decided per application based on business criticality, technical debt, remaining useful life, and available migration timeline — a legacy internal tool nearing end-of-life is a Retire or Rehost candidate; a core revenue-generating platform with years of remaining life is a much stronger Refactor candidate, since the investment pays off over a longer horizon. AWS's own guidance (and SAP-C02's own framing) treats this as a portfolio-level decision exercise, not a single architectural choice applied everywhere.

The Migration Readiness Assessment: Before the 6 R's#

Before applying the 6 R's to any specific application, most real migration programs run a Migration Readiness Assessment (MRA) first — a structured evaluation across business, process, and technical readiness dimensions (executive sponsorship, operating-model maturity, skills gaps, security/compliance posture), producing a prioritized roadmap rather than jumping straight to per-application strategy decisions. This maps directly onto AWS's own Cloud Adoption Framework (CAF), which organizes readiness across six perspectives: Business, People, Governance, Platform, Security, and Operations — a genuinely common SAP-C02 reference point worth recognizing by name, since a question framed around "organizational readiness" rather than a specific service is often testing CAF awareness specifically.

Application Discovery Service — Knowing What You Actually Have#

Part 12 mentioned Application Discovery Service briefly. The full picture: it runs in two collection modes — an agent-based collector installed on individual servers for detailed, per-process performance and dependency data, and the Agentless Collector (below) for environments where installing software on every source server isn't practical. Both feed data into Migration Hub, building the actual, evidence-based inventory a migration plan should be built from — replacing the all-too-common starting point of an outdated spreadsheet nobody has updated in two years. Retiring workloads discovered to have zero real traffic, mentioned in Part 12, is a direct, immediate output of this discovery phase.

The Agentless Collector#

For VMware-heavy environments specifically, the Agentless Collector deploys as a single virtual appliance inside the on-premises data center and discovers an entire vCenter's worth of VMs — hundreds of servers — without installing anything on each individual VM. As of late 2024/2025, it also discovers on-premises network connections (which servers actually talk to which other servers, and over which ports), directly answering the dependency-mapping question that used to require painful manual interviews with application owners who often don't fully know their own system's dependencies. This network-dependency data is exactly what feeds wave planning below — a server can't safely move to a different wave than the dependencies it actively talks to, without at minimum accounting for the resulting cross-wave latency.

Migration Evaluator — Building the Business Case#

Before committing resources to a migration program, Migration Evaluator (a free AWS service, distinct from AWS Transform's newer agentic assessment features) analyzes existing on-premises infrastructure usage data — server utilization, existing licensing, current run-rate cost — to produce a directional TCO comparison between staying on-premises and moving to AWS, typically presented to the actual budget-holding stakeholders who need a business case before authorizing a migration program at all. Where Application Discovery Service answers "what do we have and how does it depend on other things," Migration Evaluator answers the earlier, business-facing question: "is this worth doing, and roughly what will it cost."

Landing Zone Prerequisites#

A migration shouldn't land workloads into a single, undifferentiated AWS account. Part 1's multi-account landing zone (Organizations, OUs, a security-audit account, a shared-networking account) should exist before the first production workload migrates, not be retrofitted afterward — retrofitting account structure under a live workload is meaningfully more disruptive than building it first. AWS Control Tower (Part 1) is the standard accelerator for standing this up quickly, and it's common for a migration program to invest its first weeks entirely in landing-zone setup before touching a single application, precisely because everything else in this part assumes that structure is already in place.

Migration Hub — The Central Tracking Surface#

Migration Hub aggregates discovery data and tracks migration progress across every tool in this part — MGN rehosting status, DMS database migration status, Application Discovery Service inventory — from one dashboard, regardless of which specific tool is doing the actual work for a given application. This is the single-pane-of-glass answer to "what's our overall migration status" across a portfolio of potentially hundreds of applications moving through different strategies simultaneously, avoiding the need to check each underlying service's own separate console for a portfolio-level status view.

AWS Transform — Agentic Migration and Modernization#

The most significant 2026 development in this space: AWS Transform, an agentic AI-powered migration and modernization platform covering Windows, VMware, mainframe, and .NET workloads. Rather than a person manually running discovery, building a wave plan, and configuring network connectivity step by step, AWS Transform's agents automate large parts of that lifecycle directly — analyzing discovered application dependencies, business priorities, and technical constraints to propose optimized migration waves, then handling landing-zone setup, network creation, and the actual rehosting or containerization work. As of 2026, it also offers agentic assessment capabilities — what-if cost scenarios, customizable assumptions, and multi-format TCO analysis — automating what used to be a heavily manual, consultant-driven business-case exercise.

AWS Transform MGN — Rehosting, Revisited#

Confirmed as of June 2026: AWS Application Migration Service (MGN) was rebranded to AWS Transform MGN, reflecting its role as the replication engine powering AWS Transform above. Functionally, it's still the same rehosting mechanism Part 12 introduced — any documentation, exam material, or older tutorial still calling it "Application Migration Service" or plain "MGN" is describing the same underlying service under its prior name, not a different product. It retains its compliance certifications (FedRAMP High, HIPAA, PCI DSS, ISO, SOC) and remains available across every commercial region plus GovCloud.

How MGN Actually Works: Continuous Replication and Cutover#

The key property worth internalizing: replication is continuous and block-level, running for days or weeks before the actual cutover — meaning the source system keeps running normally, fully unmodified, right up until the moment of cutover, and a test launch can validate the converted target instance boots and runs correctly without ever disrupting the still-running source. This is what makes MGN-based rehosting genuinely low-risk compared to a one-shot, all-at-once cutover: any problem discovered during a test launch gets fixed and re-tested with zero production impact, since the real cutover hasn't happened yet.

Wave Planning#

A large migration portfolio doesn't move in one shot — it moves in waves, grouped by dependency (applications that talk to each other move together, or in adjacent waves with a defined cutover order), risk tolerance (lower-risk, non-critical applications often go first, both to build team confidence and to surface process gaps before higher-stakes applications follow), and team capacity (only so many applications can be actively cut over and validated at once without overwhelming the team doing it). AWS Transform's agentic wave-planning capability, above, automates a first-pass version of this grouping directly from discovered dependency data — a genuine time savings over building the same groupings by hand from a dependency spreadsheet.

Database Migration Service, Revisited for Heterogeneous Migrations#

Part 6 introduced DMS for straightforward database migration. Its full relevance to this part: DMS supports both homogeneous migrations (same engine, e.g., on-premises PostgreSQL to RDS PostgreSQL — straightforward, minimal schema translation needed) and heterogeneous migrations (a different engine entirely, e.g., Oracle to Aurora PostgreSQL) — the latter being a genuinely common, high-value modernization move (escaping expensive commercial database licensing) but requiring real schema and code translation the source and target don't share.

DMS Deep Dive: Full Load, CDC, and Full Load + CDC#

DMS replication tasks run in one of three modes, and choosing correctly matters for both migration speed and cutover downtime: Full Load copies existing table data once, with no ongoing replication — the fastest option for a table that can tolerate a full stop during the copy, and appropriate only for genuinely small, low-change tables. CDC (Change Data Capture) replicates only ongoing changes from a defined starting point, assuming an initial full copy already exists via another means. Full Load + CDC, the standard choice for a production cutover, does the full copy first and then seamlessly continues with CDC from the exact point the full load captured — giving the source database an unbroken replication stream right up to the actual cutover moment, the database-specific instance of the same "keep the source live until the last possible second" principle already established for MGN.

The Schema Conversion Tool#

For heterogeneous migrations, AWS Schema Conversion Tool (SCT) automates the schema translation step — converting table definitions, stored procedures, and functions from the source engine's dialect to the target's — and flags what it can't automatically convert (proprietary stored-procedure logic with no direct equivalent, for instance) for manual rework. DMS then handles the actual data movement and ongoing replication during the cutover window, so the source database keeps accepting writes right up until the final switch — the same "keep the source live until the last possible moment" principle MGN applies to compute, applied here to databases specifically.

Moving Data at Scale: The Decision Framework#

Before covering each data-movement service individually, the actual decision they collectively answer: how much data, over what network bandwidth, in how much time decides whether an online (network) or offline (physical) transfer path makes sense at all. The classic back-of-envelope math: a sustained 1 Gbps connection realistically moves roughly 10 TB per day accounting for real-world overhead — a petabyte-scale migration over that same link would take months, easily justifying a physical alternative if enough data were involved. (Given the 2026 Snow Family changes below, that physical alternative today points increasingly toward AWS Data Transfer Terminal rather than a device shipped to the customer's own site.)

AWS DataSync — Online, Automated Data Transfer#

DataSync automates online transfer between on-premises storage (NFS, SMB, a self-managed object store) and AWS storage (S3, EFS, FSx), or between two AWS storage services, handling network optimization, scheduling, data integrity verification, and incremental transfers automatically — re-running a DataSync task after the first full copy only moves what's actually changed, the same delta-based efficiency principle familiar from rsync. It requires a DataSync agent deployed on-premises (a VM image) for on-premises sources, communicating outbound to the DataSync service, avoiding the inbound-firewall-hole problem a naive transfer approach might otherwise require.

DataSync Enhanced Mode for Cross-Cloud Transfers#

A genuinely new 2025/2026 capability worth knowing specifically: DataSync's Enhanced mode supports cross-cloud transfers (AWS to/from another cloud provider) without requiring a DataSync agent at all — removing a real deployment step for the increasingly common multi-cloud migration or ongoing data-synchronization case, where installing and maintaining an agent VM in a third-party cloud environment was previously the friction point. This is directly relevant to any organization migrating away from another cloud provider entirely, or maintaining a permanent multi-cloud data pipeline post-migration.

AWS Transfer Family — Managed File Transfer#

Transfer Family provides fully managed SFTP, FTPS, and FTP endpoints backed by S3 or EFS — for the specific, common case of external partners or legacy systems that only speak one of those protocols and can't be changed to call an S3 API directly. This isn't a bulk-migration tool in the same sense as DataSync or MGN; it's an ongoing integration service, commonly kept running well past the migration itself to preserve a partner integration that depends on SFTP specifically, without forcing that partner to adopt a new protocol on the organization's own migration timeline.

The Snow Family, and Its 2026 Reality#

Worth stating with full currency accuracy, since this is a real, significant, and recent change: AWS closed the Snow Family to new customers on November 7, 2025. The Snowcone devices and earlier-generation Snowball devices were already discontinued in November 2024 (support for existing customers continuing through November 2025); as of the 2025 closure, only the Snowball Edge Storage Optimized (210 TB) device remains available, and only to existing customers — a brand-new AWS customer today cannot order any Snow Family device at all. AWS's own stated direction is winding the family down in favor of online transfer (DataSync) and physical drop-off locations (AWS Data Transfer Terminal, below). Any exam material, tutorial, or mental model still treating "order a Snowball" as a routine, universally-available large-data-migration option is describing a capability that, for a new customer, simply no longer exists.

AWS Data Transfer Terminal#

The service actually replacing Snowball's role for new customers: AWS Data Transfer Terminal is a physical, secure facility (expanding through 2026 — Seattle, Phoenix, London, Paris, Sydney, Tokyo, San Francisco, Los Angeles, New York, Munich, among the confirmed locations) where a customer physically brings their own storage hardware and connects it to high-throughput network infrastructure (at least dual 100G fiber) on site, transferring data directly over that connection rather than shipping a device back and forth. This is a meaningfully different model than Snowball's "AWS ships you a device, you fill it, you ship it back" — here, the customer's own hardware never leaves their possession, and the transfer happens at terminal-grade network speed in one visit rather than over days of shipping transit in each direction.

AWS Storage Gateway — A Bridge, Not Just a One-Time Transfer#

Distinct from the one-time or scheduled transfer tools above, Storage Gateway provides ongoing, hybrid storage connectivity — an on-premises appliance (virtual or physical) presenting AWS storage through a familiar on-premises protocol. File Gateway presents an NFS/SMB share backed by S3; Volume Gateway presents iSCSI block storage backed by EBS snapshots (in either cached or stored mode, trading local storage footprint against latency); Tape Gateway presents a virtual tape library backed by S3/Glacier, letting an existing backup application keep believing it's writing to physical tape. This is the right tool specifically for a long, gradual migration or a genuinely permanent hybrid architecture, distinct from DataSync's one-time-or-scheduled-batch model — an application that can't be fully cut over yet keeps working against what looks like local/on-premises storage, while that storage is transparently backed by AWS underneath, with no big-bang cutover moment required at all.

Choosing a Physical vs Network Transfer Path#

For most organizations without an existing Snow Family relationship, DataSync and Data Transfer Terminal are now the two real options — the decision tree has genuinely changed shape from what older migration guidance describes.

Network Foundations for a Migration#

A migration's data-movement plan is only as good as the network path underneath it. Direct Connect (Part 4) is the standard choice for a sustained, high-volume, ongoing migration effort — a dedicated, predictable- bandwidth private connection avoids both the variability of internet-based transfer and, for a long-running multi-month migration, can be materially cheaper than paying internet data-transfer rates for the full volume moved. A Site-to-Site VPN (Part 4) is a reasonable, faster-to-provision fallback for a smaller migration or while a Direct Connect circuit is still being provisioned (which itself commonly takes weeks).

Modernization Beyond Rehosting: Refactor Patterns#

For applications chosen for Refactor rather than Rehost, the concrete architectural patterns are exactly what earlier parts of this series already cover — this part's job is connecting them to the migration context specifically: strangler fig (incrementally routing traffic for individual features from a legacy monolith to new, cloud-native services behind the same API Gateway, Part 13, until the monolith is eventually fully replaced, never a single risky big-bang rewrite), decomposition into microservices on ECS/EKS/Lambda (Part 7), and database modernization alongside the application layer (moving off a commercial engine to Aurora, Part 6, often bundled with the same migration wave as the application refactor since the two are frequently coupled).

Mainframe and VMware Modernization#

Two specific, heavily SAP-C02-relevant modernization categories worth naming directly: mainframe modernization (AWS Transform's own stated focus area) typically involves automated code analysis and transformation of COBOL/PL/I workloads toward modern languages and cloud-native runtimes, a genuinely different discipline from a standard application rehost given mainframe workloads' unique batch-processing and transaction-integrity characteristics. VMware modernization covers organizations moving off on-premises VMware — either rehosting VMs as EC2 instances via MGN, or, for organizations wanting to keep a VMware-compatible operating model temporarily during a longer transition, running on VMware Cloud on AWS as an intermediate step before a fuller cloud-native refactor.

Cutover Strategies and Minimizing Downtime#

The actual cutover moment — the point where production traffic moves from source to target — benefits from the exact same deployment-strategy vocabulary already covered in Parts 7 and 14: a DNS-based cutover (Route 53, Part 8, with a low TTL set well in advance) shifting traffic once the target is validated, a blue/green cutover keeping the source fully intact as an instant rollback target, or, for a database, a carefully sequenced read-replica promotion (Part 6) minimizing the write-downtime window to the smallest possible cutover gap. None of this is new mechanism — it's applying tools this series already taught, at the specific, higher-stakes moment a migration's cutover represents.

Rollback Planning — The Step Migrations Skip#

The single most common real-world migration failure isn't a bad migration — it's a migration with no tested rollback path when something goes wrong post-cutover. Because MGN/DMS's continuous replication keeps the source system fully intact and running right up until cutover, the source remains a legitimate rollback target for a defined window after cutover — but only if that window, and the actual mechanics of reverting DNS/traffic back to it, were planned and tested before cutover, not improvised during an incident. Treat "how do we get back to the source system if this goes wrong" as a mandatory planning question for every wave, not an afterthought only considered once something has already broken.

Cost During and After Migration#

Two distinct cost phases worth separating: during migration, a workload often runs in both source and target simultaneously for a period (the whole point of continuous replication), meaning a temporary, real cost overlap should be budgeted for explicitly rather than surprising a finance stakeholder mid-project. After migration, Part 16's full cost-optimization toolkit applies immediately — a freshly rehosted workload, moved as-is with minimal changes by design, is very often running oversized or on the wrong purchasing model, making the first Compute Optimizer/Cost Explorer review post-migration a near-guaranteed source of quick wins.

Security During Migration#

Migration introduces its own temporary attack surface worth treating deliberately, not as an afterthought: replication agents (MGN, DataSync) need appropriately scoped IAM roles and network paths (Part 2, Part 4) rather than broad, temporary "make it work" permissions left in place after the migration completes; data in transit during replication should be encrypted (both MGN and DataSync encrypt in transit by default); and a migrated workload's security posture — security groups, IAM roles, encryption at rest — should be explicitly reviewed against this series' Part 9 baseline rather than assuming a lift-and-shift preserved whatever security configuration existed on-premises, since an on-premises network's implicit trust boundaries (a flat internal network, for instance) rarely translate safely into a cloud VPC without deliberate reconstruction.

A Full Worked Example: Migrating a Three-Tier Application#

A mid-sized organization migrating an on-premises three-tier application (web tier, application tier, Oracle database) to AWS:

1. Discovery: The Agentless Collector runs against the VMware environment hosting all three tiers, surfacing CPU/memory utilization history and, critically, the network dependency data confirming which other internal systems the application tier actually talks to.
2. Strategy selection: The web and application tiers, both stateless and low-complexity, are chosen for Rehost via AWS Transform MGN; the Oracle database, given its licensing cost, is chosen for Replatform to Aurora PostgreSQL via DMS + SCT — a mixed-strategy portfolio decision, not a single choice applied uniformly.
3. Wave planning: Given the discovered dependency, the application tier and database are grouped into the same wave (their tight coupling makes an isolated cutover of just one of them risky); the more loosely coupled web tier gets its own, earlier wave to validate the MGN process on lower-risk traffic first.
4. Data movement: The application's file-storage volumes migrate via DataSync over a newly provisioned Direct Connect circuit, running incrementally for two weeks before cutover; the Oracle-to-Aurora schema conversion runs through SCT, with the handful of proprietary stored procedures SCT couldn't auto-convert flagged for manual rework by the DBA team.
5. Cutover: MGN test launches validate the converted web/app-tier instances non-disruptively while the source keeps serving production traffic; DMS ongoing replication keeps Aurora in sync with Oracle right up to the final cutover window, minimized to a low-traffic maintenance period.
6. Rollback readiness: The source VMware environment is deliberately kept running and untouched for two weeks post-cutover, with a tested, documented DNS-revert procedure — not needed in this case, but confirmed rehearsed before cutover, not assumed.
7. Post-migration: Compute Optimizer (Part 15) flags the rehosted instances as meaningfully over- provisioned within the first week, exactly as expected for an as-is lift-and-shift; a right-sizing pass and a Savings Plan purchase (Part 16) follow once the new steady-state usage pattern is confirmed stable.

Migration Best Practices — The Consolidated Checklist#

• Run Application Discovery Service (agent-based or Agentless Collector) before finalizing any migration plan — a plan built on an outdated spreadsheet routinely misses critical dependencies.
• Choose a migration strategy per application, not one strategy for the entire portfolio.
• Group applications into waves by actual discovered dependency, not by convenience or org-chart boundary.
• Keep the source system fully intact and running until cutover is confirmed successful — continuous replication exists specifically to make this possible with minimal risk.
• Plan and test the rollback path for every wave before cutover, not after something breaks.
• Budget explicitly for the temporary cost overlap of running source and target simultaneously during migration.
• Review a freshly migrated workload's security posture against this series' Part 9 baseline rather than assuming a lift-and-shift preserved appropriate controls.
• Run a right-sizing pass immediately after migration — an as-is rehost is very often oversized by design.
• Confirm current Snow Family eligibility before including it in a migration plan — it's closed to new customers as of November 2025.

Part 17 CLI Cheat Sheet#

Common Mistakes and Interview Traps#

Worked Practice Problems#

Problem 1: A team is migrating 200 TB of data from an on-premises data center with a 500 Mbps internet connection and a hard 30-day deadline. Would DataSync over that connection meet the deadline, and if not, what's the current (2026) recommended alternative?

Answer: No — 500 Mbps realistically moves roughly 5 TB/day accounting for overhead, meaning 200 TB would take around 40 days, past the 30-day deadline. Since the organization has no existing Snow Family relationship (the family closed to new customers in November 2025), the current recommended alternative is AWS Data Transfer Terminal — physically bringing storage hardware to a terminal location and transferring over its high-throughput on-site network connection, completing in a fraction of the time a constrained internet link would take.

Problem 2: A migration team wants to validate that a rehosted EC2 instance boots correctly and passes application health checks before committing to a production cutover, without any risk to the still-running source system. What MGN capability provides this, and why is it safe?

Answer: MGN's test launch capability. It's safe because MGN's replication is continuous and the staging area is separate from the actual cutover action — launching a test instance from the replicated staging data doesn't touch, pause, or otherwise affect the source system, which keeps running and replicating normally throughout the test. Only start-cutover actually finalizes the migration.

Problem 3: A heterogeneous database migration (Oracle to Aurora PostgreSQL) needs several complex stored procedures translated, and the team discovers AWS Schema Conversion Tool can't automatically convert some of them. What's the correct response, and why doesn't this mean DMS/SCT are the wrong tools for this migration?

Answer: SCT flags what it can't auto-convert specifically so the team can manually rework just those specific pieces, rather than either blocking the whole migration or silently producing an incorrect translation. This is expected, normal behavior for a heterogeneous migration involving proprietary database-specific logic — SCT and DMS still handle the overwhelming majority of the schema translation and all of the actual data movement/ongoing replication automatically; the manual rework is a bounded, known gap, not a sign the tooling is unsuited to the migration.

Summary and What's Next#

Migration is a portfolio decision exercise as much as a technical one — the 6 R's applied per application based on business value and complexity, discovered through Application Discovery Service rather than assumed from a stale inventory, and tracked centrally through Migration Hub. AWS Transform and its MGN rehosting engine (the 2026 rebrand of Application Migration Service) provide continuous, low-risk replication and test-before-cutover safety; DMS and SCT do the equivalent for heterogeneous database migrations. And two real, current-as-of-2026 shifts are worth carrying forward specifically: the Snow Family's closure to new customers, replaced by DataSync and AWS Data Transfer Terminal, and MGN's rebrand under the AWS Transform umbrella — both easy to get wrong from stale training data or an older tutorial, and both squarely testable on SAP-C02's heaviest-weighted domain.

Part 18 moves from moving data to actually deriving value from it at scale: Glue, Kinesis, EMR, Redshift in depth, Lake Formation, Athena, MSK, and QuickSight — the full data-engineering toolkit this series has only touched in passing until now, and all of DEA-C01's exam scope.