Sequencing a website redesign around enquiry delivery
Follow a fictional enquiry from acceptance through delayed CRM delivery and application rollback, then use those boundaries to plan a redesign release.
Separate the page release from the enquiry record
A redesign release can change the page a buyer reads, the endpoint receiving the form and the system that sales uses to follow up. A working page does not establish that the receiving team has the enquiry. I recommend planning these boundaries separately before deciding which changes belong in the same release.
Begin with the paths currently used by sales and marketing: the proposal link someone sends, the campaign destination and the form behind its call to action. Name the owner who can verify each path. Keep an active path usable while its replacement is reviewed. An unfinished service page is not an equivalent destination merely because it has the new branding.
The timeline below is fictional, not a production incident or an executed recovery test. It assumes one persistent enquiry store, an operator-visible delivery queue and a CRM test destination. The previous application can read the same records and delivery states. These are conditions to verify in a real system, not capabilities supplied by this article. No sales continuity or conversion result is claimed.
Prepare a release that can return to the previous application
For this scenario, release B changes the service-page layout and CRM connector. Release A is the previous application. The public URLs and form field contract stay the same. A and B both understand accepted enquiries with pending or delivered status. Returning to A does not restore an older database. If A cannot read the new records, it is not a usable recovery target under this plan.
I recommend postponing the connector change when the layout can ship against the existing endpoint. That reduces the number of changed boundaries to investigate. If the connector must ship with B, require separate evidence for acceptance and receipt. A success banner alone cannot answer both questions.
Before cutover, rehearse B and A against synthetic records in an isolated environment. Record the release identifiers and the compatible schema. Confirm the operator can find an accepted record after changing the application version. Exercise rejected input and a dependency outage, then inspect the receiving test system. A checkbox saying “rollback available” supplies none of that evidence.
Work through accepted, pending and retried delivery
Fictional step one — before cutover: A is serving the site. An older synthetic enquiry, E-40, is already delivered. Record its presence as a reference point. It is not a reason to restore the whole store later. No schema change is part of this exercise.
Fictional step two — after B is enabled: a new synthetic enquiry, E-41, is committed to the shared store with delivery pending. Only after that commit does the browser receive an acceptance confirmation and reference. In this stipulated system, the record establishes acceptance. The confirmation does not establish CRM receipt. A different implementation would need its own definition and evidence of acceptance.
Fictional step three — the dependency fails: the test CRM rejects the connector attempt without creating a record. E-41 remains accepted and pending, and the operator can see the failed attempt. I recommend stopping further connector attempts while the cause is investigated. Telling the buyer to resubmit would create another enquiry rather than repair delivery of E-41.
Fictional step four — return to A: the release owner restores application A with its matching routing configuration, leaving the shared store intact. E-40 is still delivered and E-41 is still pending. The operator can read both. A later synthetic enquiry, E-42, is accepted through A into that same store. Replacing it with the pre-cutover snapshot would remove E-41, and would also remove E-42 if the snapshot were restored after that acceptance.
Fictional step five — recover delivery: after the connector is corrected, the operator retries the known rejected attempt for E-41 using its existing reference. The test receiver records it and provides a receipt tied to that reference. Only then is E-41 marked delivered. Returning the application to A did not itself complete this work. Recovering delivery required the pending record and separate receiving evidence.
Handle an uncertain result differently from a known rejection
The timeline assumes the rejected attempt created nothing at the receiver. A timeout after sending is a different case: the CRM might have created a record even though the sender never obtained its response. Local pending status would not settle that uncertainty.
I recommend reconciling that attempt against the receiver before authorizing a manual replay, or relying on a verified receiver-side deduplication contract if one exists. Keeping the same enquiry reference helps correlate evidence, but does not by itself make an external create operation idempotent. Do not label it safe to retry merely because the local record exists.
The exercise does not implement a queue, deduplication or reconciliation. It does not test concurrency, database restoration or an incompatible schema migration. For an actual release, a rehearsal must demonstrate the claimed recovery behavior. If accepted records cannot be preserved and read by the recovery application, revise the release plan rather than asserting the rollback is ready.
Keep URL migration and form feedback in the review
Google’s site-move guidance concerns URL changes. It recommends mapping old URLs to corresponding destinations and, for small or medium sites, moving the URLs together. That does not require developing every template at once. The same guidance recommends separating major changes such as a domain move and a new layout, and warns that search visibility can fluctuate. It does not promise uninterrupted enquiries or sales.
For the fictional release, stable URLs avoid adding a URL migration to the connector investigation. For a project that does change URLs, review campaign and proposal links against the actual mapping. Do not redirect an old service page to an unrelated homepage simply to avoid an error response; Google specifically warns against irrelevant destinations.
W3C’s form-notification guidance calls for understandable submission feedback, errors associated with the relevant controls and guidance on correction. Review that experience with a keyboard and on a narrow screen. An accessible-looking message still needs to describe the actual application outcome. Wording cannot turn pending CRM delivery into a received enquiry.
Close the release against named evidence
I recommend keeping the release open until the application owner can identify the active version, the acceptance owner can trace synthetic submissions and the receiving team can verify their destination. Retain the evidence needed to distinguish an accepted record awaiting delivery from a failed attempt to accept anything. Use marked synthetic data and avoid personal information in review screenshots.
Route errors and rejected submissions need immediate investigation. Search reporting answers a different question over time. Record the cutover and any measurement changes before interpreting outcomes. This example supplies no traffic baseline or sales comparison. Its useful result is a recovery decision that preserves the accepted enquiries rather than treating the database as part of the page design.