Paul A.
Forum Replies Created
-
Hi @frankremmy,
This issue is separate from the current ticket. When we contacted support approximately a year ago during our subdomain migration, we were advised that there was an existing connection related issue at that time.
Hi @lovingbro,
Apologies for the delayed response, I was away for a couple of weeks.I wanted to clarify one point regarding our earlier migration attempt. When we migrated a full backup of our main site into a subdomain, we did not retire or decommission the original domain at that time. Sorry for any confusion there.
One of our teammates previously reached out to WooCommerce support, and it was mentioned that there may have been an existing connection related issue, which could explain why the subdomain appeared to break after the migration. Based on that guidance, we wanted to check in and confirm whether that underlying connection issue has since been addressed on your end.
Understanding this will help us better plan the correct sequence for reconnecting services and safely transitioning traffic without disrupting subscriptions or renewals.
Thanks in advance for the clarification, and we appreciate your continued help.
Hi @lovingbro,
Thank you for the detailed explanation in your previous reply, it was very helpful for our internal risk assessment and planning.
Based on that guidance, we are now planning around a full site or full database migration approach rather than a selective export. Our target architecture is for WooCommerce, WooCommerce Subscriptions, LearnDash, users, and orders to live on a subdomain, while the main domain will be reduced to marketing pages only.
With that in mind, we wanted to ask a few follow up questions specific to subdomain migrations:
- After a full site or database migration to a subdomain, are there any WooCommerce or WordPress settings that must be reviewed or updated to ensure proper operation on the new domain?
- Are there any WooCommerce Subscriptions specific settings or post migration steps required to ensure renewals, retries, and scheduled actions continue to function correctly?
- Are there known considerations around Action Scheduler, cron, or background processing when the site is moved to a subdomain?
- For payment gateways, are there recommended steps beyond updating webhook URLs to ensure stored payment tokens and renewals continue to work after a domain change?
We also wanted to highlight a prior issue we encountered during our last year’s attempt when we migrated the site and then effectively “turned off” or decommissioned the main domain, we observed that the WooCommerce connection on the subdomain appeared to break after the migration. We are trying to better understand:
- Whether there are dependencies or references that remain tied to the original domain after migration
- The correct or supported way to disable or retire the original site without impacting WooCommerce or Subscriptions functionality on the subdomain
Our goal is to ensure that once the migration is complete, the subdomain can operate fully independently without relying on the original site, and without interruption to active subscriptions, renewals, or customer access.
Any best practices, settings to review, or documentation you can point us to would be greatly appreciated.
Thanks again for your time and guidance.
Best regards,
PaulHi WooCommerce Support Team,
Thank you for the detailed explanation, that was very helpful!
As a follow up, we wanted to ask from a purely technical and informational perspective, even if it falls outside supported workflows.
If a team were to pursue a selective, database level migration rather than cloning the entire site and cleaning it afterward, is there any guidance you can share on:
- Which specific database tables are considered critical for WooCommerce and WooCommerce Subscriptions to function correctly (for example, orders, subscriptions, Action Scheduler, customer meta)
- Whether there is a known minimum set of tables that must be migrated together to preserve relationships between users, orders, subscriptions, and renewals
- Any tables that are commonly overlooked but essential for subscription continuity, such as scheduled actions or gateway token storage
- Whether LearnDash integrations introduce additional tables or dependencies that should be considered in this scenario
We understand this approach would be unsupported and higher risk, but having clarity on table level dependencies would help us assess feasibility and risk internally before deciding on a final migration strategy.
Thanks again for your transparency and guidance.
Best regards,
Paul