A staging copy looks correct and is about to replace the live site. Which functional checks, external integrations and data changes should be reviewed before launch?

A staging copy that looks correct has passed a visual check, but launch also depends on behavior and data. For this hypothetical handover, build a short acceptance list from what visitors and editors actually do. Test navigation, search, login, permissions, publishing, media, forms and any checkout or membership workflow that exists. Include a mobile viewport and an anonymous session, then verify that submissions reach the intended test destination.

Review external integrations individually: email delivery, payment mode, API keys, webhooks, scheduled tasks, analytics and remote storage. A copy can retain production credentials or callback URLs. During testing, isolate integrations that could send messages or change real records. Before launch, explicitly confirm which settings must become production settings and who will verify them.

The data plan matters just as much. Identify new orders, registrations, comments and editorial changes created on the live site since staging was copied. Replacing the live database wholesale could discard them. Decide whether to deploy files only, transfer selected changes or coordinate a controlled final synchronization, using a method appropriate to the site's data.

Also check the final domain, HTTPS, redirects, stored URLs and cache behavior. Migration tools must handle WordPress data structures correctly rather than applying an indiscriminate text replacement. Keep a recent backup and a practical rollback procedure with clear checks for success. After traffic moves, repeat the critical workflows and inspect errors and external deliveries. Record what was tested so that an attractive homepage is not mistaken for complete acceptance.

Sources: WordPress search and replace and Migrating WordPress.