Setting the file. One moment.
Chapter 45 · Amazon Opensearch Service
Subchapter 45.28
references/readiness-rubric.mdMarkdown3 KBView on GitHub
Canonical 7-dimension scoring for the FULL_ASSESSMENT readiness score (0–100, GREEN/YELLOW/RED). Cited from assessment-shape-full-assessment.md §6, assessment-workflow.md §Step 7, and the various report templates in assets/.
| Dimension | Weight | What it captures |
|---|---|---|
| Compatibility | 25 | Number/severity of risk-blocker-lane gap-register entries (see compatibility-rubric.md §2. migration-specific-lane entries do NOT deduct from this dimension because the migration plan already includes the remediation.) |
| Operational readiness | 15 | Team familiarity with OpenSearch, on-call coverage. |
| Sizing fitness | 15 | Confidence in instance class + count for projected workload. |
| Data-movement complexity | 15 | Volume, transformations, cutover style. |
| Cutover complexity | 10 | Downtime tolerance, dual-write feasibility, rollback plan. |
| Sizing-input completeness | 10 | How much sizing input the customer provided. |
| Stakeholder alignment | 10 | Sign-off from product/security/infra. |
migration-specific lane is presentation, not a deduction. A row with a clean transformer/config remediation that the migration plan already includes does not lower the Compatibility dimension. It is surfaced in §7 Migration specifics of the assessment so the customer knows what the path handles, but it is not scored as a gap.risk-blocker lane drives the Compatibility deduction. Each BLOCKING/HIGH risk-blocker row deducts; MEDIUM and LOW risk-blocker rows deduct less. Use the Severity table in compatibility-rubric.md §1 to weight.assessment-gotchas.md when scoring Compatibility — many gotchas are not in any AWS doc and missing them is the most common readiness gap. Whether the gotcha contributes to the deduction depends on its Category: tag (TRUE_BLOCKER / MIGRATION_SPECIFIC / OPERATIONAL_CONSIDERATION / COST_TCO / CLARIFICATION) — only TRUE_BLOCKER and MIGRATION_SPECIFIC-with-customer-action items deduct from Compatibility.risk-blocker row caps the readiness tier at YELLOW regardless of total score, until the customer commits to the remediation path. This applies to Lucene segment wall (gotcha #3), ES ≥ 7.11 snapshot lockout (#2), Solr→OS document-level (#1), and similar.A Solr 8.11 → OS 2.19 migration with: q.op=AND (HIGH, migration-specific), fielddata strip (BLOCKING, migration-specific), 4 custom JARs needing port (HIGH, risk-blocker), Solr→OS document-level (BLOCKING, risk-blocker), and full operational/cutover/stakeholder readiness:
The two migration-specific items (q.op=AND, fielddata) are surfaced in §7 Migration specifics but do not affect the Compatibility score, because they are part of the migration plan, not gaps in it.