Before you start
Identify the actual WordPress source, frontend, Daymerce organisation and installed capabilities. Separate the production and test environments.
A recognisable example
DYMR edits a product in Daymerce. The reviewed change goes to WooCommerce; the storefront then needs the confirmed source result, not an unverified editor preview.
Step by step
- Map core products, orders, customers and media to the shop's WordPress/WooCommerce source. Keep originals and large files in the user-owned environment where the supported flow provides that.
- Map Daymerce's necessary working data separately: account and organisation access, compact projections, plans, job references and audit or verification records.
- For each frontend module, record which approved configuration runs locally, its validity and fallback. Native WooCommerce purchase processing must not depend on a synchronous Daymerce cloud request.
- Check the actual write, readback and storefront-verification path. Record any explicit external processor and its data scope rather than assuming that no data ever leaves the shop.
What you should see
Your architecture distinguishes authoritative shop data, local runtime configuration and Daymerce working data. The user-owned direction is not evidence that every existing feature has already moved all processing or storage locally.
If it does not work
Cannot place a data type? Trace its actual feature implementation and retention before promising deletion or independence. Disconnecting does not automatically erase working history or uninstall local modules.
Menu names and available actions depend on your app language, permissions and connected shop. Screens show the real Daymerce interface with fictional DYMR data; original screen labels are preserved.