Skip to content

PATTERN Cited by 1 source

Risk-based sequencing

What it is

Risk-based sequencing is the migration-ordering pattern where independent migration units are ordered by ascending risk — lowest-risk environments, tenants, or workloads first; highest-risk production workloads last — so tooling and operational runbook mature on low-stakes stages before they touch critical ones.

The ordering is deliberate: every stage is an opportunity to discover latent issues, and the cost of discovery is strictly ordered with the criticality of the stage. Finding issues on stage 1 is cheap; finding them on stage N is catastrophic.

Shape

  1. Classify units by risk. A migration unit (cluster, tenant, environment) has a risk score computed from: traffic volume, data criticality, SLA commitments, blast radius of a partial regression, recoverability.
  2. Order ascending. Lowest risk first; highest risk last.
  3. Apply the migration unit-by-unit in order, often with soak times between stages.
  4. Learn between stages. Lessons learned on stage k update the runbook, tooling, and policies used for stage k+1. The risk-based ordering is what makes these learning cycles cheap.
  5. Halt / re-plan if a stage surfaces severe issues. The pattern's value is that you've spent learning on easier stages; escalation to re-planning is still cheaper than having hit it on prod.

Salesforce canonical instance

The Salesforce Karpenter migration post names the sequencing pattern explicitly as its own bullet in the rollout strategy:

*"A deliberate, phased rollout strategy was adopted:

  • Mid-2025 to Early 2026 – A multistage migration across internal environments with soak times between stages
  • Start with lower-risk environments – Less critical workloads were migrated first to validate tooling and operational processes
  • Risk-based sequencing – High-stakes production environments continue to be migrated last after testing the process"* (Source: sources/2026-01-12-aws-salesforce-karpenter-migration-1000-eks-clusters)

Two separate bullets covering the same principle — starting with low-risk, ending with high-risk — signalling how load-bearing the ordering is to the overall rollout safety.

Supporting quote: "By using this approach Salesforce, continuously learned and adapted, avoiding large-scale regressions." The learning loop is the direct benefit.

Pairs with, distinct from

Trade-offs

  • Risk classification is imperfect. Labelling environments as "low-risk" and "high-risk" sometimes hides issues: a low- risk environment might lack the workload diversity to expose bugs that only appear at prod scale. Mitigation: include at least one mid-risk stage that resembles prod's workload character.
  • Long calendar time. Strict risk ordering means the whole migration is rate-limited by the slowest stage. Salesforce's rollout was 6+ months.
  • Re-ordering opportunities. Sometimes a high-risk unit can be migrated first because its high visibility forces you to build the right tooling. This is the reverse of the pattern and sometimes appropriate — but it's the exception, not the default.

Seen in

Last updated · 200 distilled / 1,178 read