A missing custom question should stop your checkout switch if the business needs its answer and you have not verified a working replacement. If the question no longer serves a necessary purpose, deliberate retirement may be better than rebuilding it.
Start by asking the person who uses the answer: “What cannot happen correctly without this information?” A successful test payment does not establish whether the missing question matters, its validation works or its answers are saved.
Establish what the question is for
Focus on one merchant-added, order-level question. Identify its exact label, when it should appear, whether an answer is required and who uses it.
Ask that person to name the task or decision the answer supports. “We have always asked” is not an operational purpose. Check exceptional orders before deciding that an apparently unused question is unnecessary.
Distinguish necessary information from a mandatory field. Information needed for certain orders need not be required for every shopper.
Start a one-field migration record
Keep this compact record open as you work. Mark unknowns as unverified rather than filling gaps with assumptions.
- Question: label, purpose, applicable orders, required status, responsible staff role and consequence of a missing answer.
- Checkout and supplier: assigned checkout page, confirmed implementation, supplying extension or customization, installed version and configuration.
- Classic baseline: results and evidence for visibility, blank submission and saved answer.
- Blocks comparison: results for the same checks, candidate replacement details and unresolved issues.
- Decision: deliberately retire, accept a verified replacement or postpone; include the reason, owner and next action.
Confirm the checkout and identify the supplier
Inspect the page assigned as checkout in WooCommerce, then open it in the editor. Confirm whether the checkout shoppers actually reach is Classic or Checkout Blocks. Appearance and page names are insufficient evidence. If a checkout builder controls the page, ask its maintainer to confirm the implementation.
Identify what supplies the question through its configuration, active extensions and records of custom snippets or theme customizations. If the source is unclear, have the developer trace it on staging rather than editing live checkout.
Check the supplier’s documentation for the specific field and workflow, not just a general claim of Blocks support. Documentation identifies a candidate; staging evidence establishes its behavior in your store.
Where documentation is silent, mark support unverified and send the maintainer your configuration, relevant versions and observed difference.
Compare against a verified Classic baseline
Use staging with synthetic customer details and answers. Isolate tests from live charges, real recipients and production fulfilment. Use the gateway’s test mode and confirm that connected services cannot create live effects. If you cannot establish these safeguards, arrange safe testing first.
Preserve a recoverable Classic configuration before changing the checkout implementation. Keep the cart, shopper state and unrelated settings consistent between comparisons.
Run the three checks below in Classic, then repeat them in Blocks for the same cases. Cover the relevant order types and shopper routes, including guest and signed-in checkout if both need the question. These are acceptance criteria, not promises about your customization.
Visibility
Confirm that the question appears where expected with a clear label. For a question that applies only to certain orders, test both an applicable and an inapplicable case.
Blank submission
Satisfy unrelated address, shipping and payment requirements so their errors do not obscure the result.
When an answer is required, leave the question blank and verify that a clear field-related validation message prevents checkout completion. When an answer is optional, verify that leaving it blank does not block checkout. If the question should be hidden, confirm that it does not block checkout either.
Saved answer
Enter a distinctive synthetic value suited to the field. Complete checkout, open the saved order and verify that the complete answer belongs to that order and is accessible in the expected staff view.
If the answer is absent from that view, investigate storage and display separately rather than assuming either worked.
Record each check as passed, failed or unverified, with the configuration, screenshot or test order identifier needed to review it. If Classic fails too, you do not yet have a verified fallback.
Choose a decision, not just a testing plan
Retire deliberately only when the responsible person confirms that collecting the answer is unnecessary, including exceptional cases. Update wording and procedures that still expect it. Retirement does not authorize deleting historical answers or removing an extension used for other functions.
Accept a verified replacement when the question remains necessary and the Blocks implementation passes all applicable checks. This question no longer blocks the switch; overall theme, shipping and gateway compatibility remains unproven.
Postpone when a necessary question has any failed or unverified check. A candidate awaiting testing is not an approved replacement. Retain Classic only if its baseline passed, and do not weaken an agreed requirement merely to make the migration test pass.
The following hypothetical branches show how the same missing question can lead to different decisions.
TRY THE SCENARIOS
What should happen to a missing collection contact question?
Hypothetical example: a collection-only store asks for an order-wide collection contact name. Testing is isolated from live effects and the Classic baseline has passed. These outcomes illustrate decisions; they do not test your store.
Staff confirm the answer is unnecessary
After checking exceptional orders, staff confirm they no longer use the answer. Retire the question deliberately and update the procedure that expected it.
A necessary answer has a replacement that passes
The Blocks replacement passes visibility, blank-submission and saved-answer checks for every applicable route. Record it as verified: this question no longer blocks the switch, but wider migration checks remain.
A necessary answer has failed or unverified checks
The replacement is only a candidate, regardless of whether test payments succeed. Postpone the switch, retain the tested Classic workflow and assign investigation or retesting.
Compare all scenarios
| Situation | What happens |
|---|---|
| Staff confirm the answer is unnecessary | After checking exceptional orders, staff confirm they no longer use the answer. Retire the question deliberately and update the procedure that expected it. |
| A necessary answer has a replacement that passes | The Blocks replacement passes visibility, blank-submission and saved-answer checks for every applicable route. Record it as verified: this question no longer blocks the switch, but wider migration checks remain. |
| A necessary answer has failed or unverified checks | The replacement is only a candidate, regardless of whether test payments succeed. Postpone the switch, retain the tested Classic workflow and assign investigation or retesting. |
Illustrative examples. Your selection is not saved or sent, and changes no store settings.
Finish your record with the decision and supporting evidence. Assign the next unresolved action—confirming exceptional cases, investigating a failed check or testing a candidate—to a named owner. Before changing live checkout, obtain the responsible person’s agreement to that decision.
