Restoring a QCTNH Site to a Different Domain
Restoring a QCTNH-enabled backup to a different domain is a clone/migration event, so QCTNH should not silently reuse the old site’s wake-up identity.
Expected first state
The restored database contains the old registered origin and credentials. On the new domain, QCTNH sees an origin mismatch and protects the old registration instead of automatically adopting the new hostname.
If the restore is the real replacement site
- Finish DNS, HTTPS, Joomla base-path, and canonical-URL configuration first.
- Open the restored site at the final intended origin.
- Run Check WebCron and resolve any local WebCron prerequisite errors.
- Run Test Connection to explicitly confirm the new origin and create a new QCTNH identity.
- Verify Connected and the new origin-change/registration activity.
If it is only a clone
Do not confirm the origin unless that clone should independently receive QuantaCade wake-ups. Leaving the mismatch protected prevents it from displacing the original registration.
Finish the canonical URL first
Before applying Restoring a QCTNH Site to a Different Domain, settle DNS, HTTPS, www/non-www policy, and Joomla base path. QCTNH registers an exact native WebCron endpoint whose scheme/host/path must correspond to the final site origin. Registering during an intermediate redirect state creates avoidable 301/302, TLS, or route failures.
After the public URL is stable, Check WebCron rebuilds the local native route and Test Connection confirms public reachability/identity.
Community Discussion
Want to compare scheduler workflows, share practical tips, or discuss how you use this QCTNH feature? Visit the QC Task Nudge & Health Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.