Wave Planning, Prioritization, and Assessment Governance

Why a wave is not a popularity contest

Meridian Health Systems now has 7 Rs, a Migration Hub application grouping, TCP maps, and a Migration Evaluator directional case. None of that is a schedule. Independent SAP-C02 study material by OpenExamPrep treats wave planning as the Task 4.1 skill that turns assessment into a migration factory. AWS’s application-portfolio guidance says the outcome of this stage is a high-confidence migration wave plan plus a high-level strategy for each application and a refined business case. The portfolio workstream is continuous: it feeds servers to the factory until the program ends. AWS’s large-migration portfolio playbook describes one to two weeks of detailed assessment per wave and a habit of planning four to five waves ahead so the migration workstream never starves.

A wave is typically four to eight weeks and follows a repeatable structure: detailed assessment, migration readiness, infrastructure build and test, data transfer, cutover, and wave closure (lessons learned, leftover defects). That duration is a planning default, not a service quota. If Meridian tries to cut 40 tightly coupled applications in two days because a vice president picked them, the factory model has already failed.

Inputs to a high-confidence wave plan

AWS’s portfolio-analysis stage lists the ingredients you combine—not a single score.

AWS tells you to document measurable business outcomes and KPIs per wave, evolve the business case with actual utilization, and publish dates to avoid. Assumptions from the assess phase should be nearly gone before you lock wave 1.

Dependencies decide who travels together

High-confidence dependency data is required to validate application groups. Communication data says which systems chat constantly. Operational data says which teams must be in the same war room. Those facts dictate which applications must move at the same time and which can operate from different locations—on premises talking to AWS—during a hybrid period.

Design rules that show up in Professional stems:

• If two systems exchange chatty, latency-sensitive calls, put them in the same wave (or an adjacent wave with a designed hybrid pattern such as AWS Direct Connect, not an accidental extra 80 ms).
• If A authenticates to B, moving A without B (or without a replica of B) is an identity outage, not a modernization win.
• Shared databases are gravity: several “simple” rehosts become one wave when they are secretly the same SQL instance.
• Retain the claims mainframe still couples nightly files to clinic apps. Wave plans must include a file-transfer or queue pattern for the hybrid period, or those clinic apps are not actually independent.
• Repurchase of COTS HR does not remove the identity dependency. The SaaS cutover is its own wave with directory federation, not a silent extra on a Friday rehost.

AWS also warns you to evenly distribute applications across waves by criticality and complexity. A plan that saves every hard system for “later” creates a terminal pocket of blockers. A plan that front-loads every hard system creates an early stall. Both fail the factory.

Business criticality versus technical ease

Prioritization is a two-axis problem. AWS’s prioritized-application stage exists so a subset of applications gets a detailed current-state and target architecture early, which surfaces landing-zone blockers. AWS then says, for wave sequencing, prioritize noncritical, simple applications in the first two waves.

Plot Meridian’s 200 applications:

• Low criticality, high ease: departmental wiki, an unused reporting VM. Wave 1–2 material. Prove AWS Application Migration Service, tagging, backup, and operations runbooks.
• Low criticality, low ease: a forgotten lab PC talking serial devices. Maybe retain or a tiny dedicated project—not a factory wave.
• High criticality, high ease: a well-understood x86 clinic directory with clean dependencies. Eligible after the factory is proven, still not the very first cutover if a failure would cancel clinic.
• High criticality, low ease: claims mainframe, imaging archive with residency rules, unrehearsed COTS payroll. Do not start here.

Executives often invert the axes: “migrate claims first because that is where the money is.” Money is why you cannot use claims as the learning wave. Technical ease without business cover still needs a rollback clock. Business cover without technical ease is a brand incident.

What not to migrate first

Write this list on the architecture decision record. Wave 1 is for learning the factory, not for proving courage.

Wave 1–2 at Meridian should look boring: two or three rehost applications with low patient impact, clean maps, and owners who can sit the cutover. Use them to time replication duration, cutover windows, and rollback. Only then pull a medium-critical replatform (SQL Server to Amazon RDS) into wave 3. Park repurchase of COTS on the vendor’s calendar. Keep the mainframe on retain until a separate program exists.

Governance during assessment—not after cutover

CAF Governance helps you orchestrate cloud initiatives while maximizing benefits and minimizing transformation risk. CAF Security owns confidentiality, integrity, and availability. CAF Platform owns the enterprise-grade hybrid environment. CAF Operations owns delivering services at the agreed level. CAF People owns skills and change. If those perspectives wait until after wave 1, wave 1 is an unsanctioned production change.

AWS portfolio guidance tells you to document internal processes that will hit every wave: change management, service management, architectural review boards, risk assessments, and approval workflows. Identify skills required to support each workload type and ask whether support teams can meet the wave plan. Feed portfolio data into the landing zone and migration workstreams with explicit data contracts.

Practical assessment-time controls for Meridian:

• RACI for 7 R approval (architect proposes, application owner accepts, security vetoes residency misses).
• Data classification gates: health data does not enter a sandbox account that lacks encryption and logging.
• Wave entry criteria: dependency map complete, rollback tested in a rehearsal, operations runbook signed, backup tested, identity path documented.
• Wave exit criteria: hypercare complete, lessons logged, next wave’s servers already in detailed assessment (the 4–5 wave pipeline).
• Exception path: the only way a high-criticality system enters an early wave is a documented compelling event plus extra rehearsal—not a hallway decision.
• Tooling governance: existing customers keep using Migration Hub; new 2026 projects start in AWS Transform. Do not freeze all discovery because governance is “not ready”; governance’s job is to authorize collectors with least-privilege, not to ban inventory.

Governance that only means “pause everything” is not CAF Governance. Governance that means “skip Security until after go-live” is not CAF Security.

Putting the 200-application factory in order

A defensible Meridian sequence:

1. Assessment governance and landing-zone minimum (accounts, identity federation, logging, hybrid network).
2. Retire confirmed zombies after connection checks—shrink the 200.
3. Waves 1–2: noncritical, simple rehost applications; factory rehearsal.
4. Waves 3–N: bulk rehost and selected replatform; keep complexity mixed, not stacked at the end.
5. Relocate VMware-control-plane clusters on their own calendar when that platform decision is firm.
6. Repurchase COTS HR/payroll when contracts, training, and identity federation are real dates.
7. Retain the claims mainframe and plant-floor systems until a dedicated assessment says otherwise.
8. Refactor only the few products whose current architecture cannot meet a documented business demand, preferably after they are out of the leased data center if the lease is the binding constraint.

That order is architecture. “Claims first because it is important” is not.

Wave-planning traps

1. Ranking waves only by revenue.
2. Splitting chatty dependencies across a high-latency hybrid path with no design.
3. Making wave 1 the mainframe plus unrehearsed COTS.
4. Rehosting software that is already on a repurchase path.
5. Starting waves before Platform and Security can accept them.
6. Treating portfolio assessment as a one-week project instead of a workstream that stays ahead of the factory.
7. Ignoring blackout dates and license events.
8. Using an unpublished AWS exam pass rate as a go/no-go metric. AWS does not publish exam-level pass-rate percentages.