Define readiness around a customer outcome
Begin with outcomes, not infrastructure labels. A reachable homepage is not enough if a visitor cannot complete the task that matters. For each critical journey, state who is trying to do what, what success means, and which result is unacceptable. Start with a few journeys so the team can make real decisions.
Classify each step as essential, important, or deferrable. Essential means the journey cannot finish without it; important may permit a time-limited workaround; deferrable can be omitted, delayed, or simplified. This is a product decision informed by engineering, not a universal technical ranking.
Record a usable result, such as an order is accepted and confirmation is stored, rather than only a page-response target.
Map dependencies and decide what can degrade
For every critical path, map hosting or delivery, DNS, application services, databases, authentication, email, payment, search, tags, consent tooling, and external APIs. Record the owner, support route, relevant limit, and user effect if each is unavailable. OWASP recommends insight into software dependencies; the same ownership discipline helps with operational dependencies.
A hard dependency stops the task when it fails. A soft dependency can be absent or stale while the core task still works. AWS describes graceful degradation as keeping the core function available when dependencies are unhealthy. Define a product-specific choice: hide a nonessential widget, defer a report, or present an honest fallback. Do not invent inventory, prices, order states, or payment results.
Capture purpose, owner, known limit, fallback, change contact, and last test date for each item.
Turn a traffic forecast into a capacity experiment
Use a scenario, not one traffic number. State the event, arrival pattern, request mix, signed-in share, geography, concurrent checkout or write activity, and peak period. Include a high case and assumptions. Google notes that requests can have very different resource costs, so requests per second alone can be a poor capacity model.
Test sustained, representative, end-to-end traffic against a configuration close to production, with approval and safeguards. AWS cautions against testing only components, using an unrepresentative request subset, or stopping at a small margin above expected load. Document the first constraint or slowdown. Live-production tests can affect customers; use a controlled environment unless a planned, staffed exercise is appropriate.
Keep the scenario, configuration, request mix, duration, observed constraint, capacity change, and follow-up owner.
Prepare change, rollback, and recovery choices
Before a high-stakes change, identify the artifact or configuration to restore, approval needed, authorized person, and validation method. Keep a short runbook for pausing a release, reverting a deployment, disabling a feature flag, reducing a noncritical integration, or restoring data using an approved procedure. Test the mechanics before the event; an unexercised backup or rollback plan is an assumption.
Set recovery objectives from business impact. Recovery Time Objective, or RTO, is the maximum acceptable delay before service is restored. Recovery Point Objective, or RPO, is the maximum acceptable data loss measured from the last recovery point. AWS warns against arbitrary or unrealistic targets and notes that dependency objectives affect what is achievable. Treat targets as planning goals, not customer promises.
Verify a limited, safe rollback or restoration and record what was checked, by whom, and any gap found.
Assign ownership before decisions are urgent
A contact list alone is not ownership. For each critical path, assign a business owner for the acceptable outcome, a technical owner for implementation, and a decision owner authorized to make a protective change. Name backups and clarify when a provider, agency, payment processor, or internal team owns the next action.
Run a short readiness review before traffic arrives. Walk through one dependency failure: what remains available, which lever is safe, who approves it, and how success is checked. This is proactive rehearsal, not a live-status report. Record dated actions, owners, and due dates.
Pre-authorize narrow safe actions where appropriate so protection does not wait for an unclear approval chain.
Treat payment and security-sensitive paths with extra care
Checkout readiness must preserve correctness as well as availability. Do not bypass authorization, weaken access controls, expose credentials, or casually alter payment-page scripts. PCI SSC guidance addresses authorization, integrity, and tamper detection for payment-page scripts and security-impacting HTTP headers. If the site accepts cards or uses an embedded payment frame, have the merchant, processor, acquirer, and qualified security or compliance advisers review material changes.
Keep an inventory of production scripts, integrations, versions, and account ownership, and restrict who can change them. OWASP notes that dependency inventories and version pinning can reduce uncertainty about what enters a build, while automated findings still need manual verification. These practices support readiness but do not establish PCI compliance or replace a security assessment.
Use only a processor-approved, reviewed alternative flow; never collect card data through informal channels.