Make the uncertain parts explicit.

01 / Before migration

Five decisions the formula cannot make.

An operational workbook shows what it calculates today. It may not show why the business works that way. Before quoting its replacement, separate recorded behavior from the policies the client still needs to decide.

The examples below refer to our complete synthetic quotation blueprint. They describe an invented workbook, not customer results.

1. Per line or across the order?

In the example, Quote!E13 checks the quantity in B13 against the threshold in $B$7. It returns the configured discount in $B$8 when that line qualifies. Two lines of five units do not receive the same treatment as one line of ten. Changing the replacement to an order-level discount changes behavior.

Ask: should the app preserve the per-line threshold, or does the business want a different policy?

2. Which total drives the next rule?

Quote!B19 compares B18, the sum of discounted line totals, with the freight threshold in $B$9. Using a value before discounts could change when the delivery charge applies. Trace the referenced cells before naming the rule.

Ask: should freight eligibility use this discounted total in the replacement?

3. What happens exactly at the boundary?

Use quantities just below, exactly at and just above the configured threshold. For the example threshold of ten, that means nine, ten and eleven. Keep all other inputs fixed. Record the expected discount treatment from the formula separately from the client's preferred future policy.

Ask: is the threshold inclusive, and which cases demonstrate that decision?

4. Which edits are allowed?

A spreadsheet can make it possible to type over a formula. That possibility does not establish an approved override policy. The replacement may need to reject overrides, permit them or require approval. Record the question rather than silently choosing.

Ask: who may override a calculated result, and what record must the app retain?

5. Do old quotes change when policies change?

Changing a live input can alter a workbook's calculations. That alone does not decide how an application should treat a previously issued quote.

Ask: should a saved quote preserve the policy and price used when it was issued, or recalculate using current settings?

Useful migration preparation contains a source cell, documented behavior, an acceptance example and any unresolved decision. A structural inventory helps locate the evidence; it does not answer every business question.

02 / Before handover

Ask what was actually tested.

A handover review is useful when expected behavior is agreed before testing. Start with a versioned requirement list, a staging build and disposable test accounts. State the workflows, roles, browser and exclusions.

One case, one traceable record

1. Requirement: link the case to the accepted source and version.
2. Expected result: define the outcome before executing the case.
3. Context: name the build, role, browser and fixture.
4. Steps and observation: record what was done and what actually happened.
5. Evidence and status: attach the relevant record and use the status accurately.

Missing access is not a pass. An attractive screen does not establish that a cross-role rule works. An unclear policy is a question to resolve before testing, not permission to invent the expectation.

Keep the original result when retesting

Record the retest build and observation without erasing the earlier finding. Separate setup errors from product behavior. Explain the workflows and risks outside the review. A bounded acceptance review does not certify security, legal compliance or the entire system.

Our booking-portal sample is explicitly illustrative and unexecuted. It demonstrates the format without claiming test results about a customer application. Its synthetic source requirements show what each example is supposed to check.

Before commissioning a review, compare the scope, evidence format and handling of blocked cases with the decision your team needs to make.