A WooCommerce update can leave a store with an awkward choice: accept the new default email and lose custom presentation, or keep an older override without knowing what changed. Start with a reviewed Migma reference for the desired message, then let the store developer reconcile the actual WooCommerce template. A design export cannot perform that code maintenance for you.
The useful outcome is a current template that still explains the order correctly and looks recognizably like your store. A cleared warning, a clean screenshot, and a successful delivery are separate checks. This guide gives marketers and store developers a shared acceptance process.
Published by Migma. Product guidance was checked on October 19, 2026. The workflow below is an editorial recommendation; it does not describe a native Migma installer for WooCommerce templates.
Establish which template is actually affected
Ask the store owner to open WooCommerce → Status → System Status. The official outdated-template guide explains that the report lists templates overridden by the theme or child theme and flags outdated copies.
Record the exact file and notification. An email override is different from a product-page override, even when both appear in the same report. Also record the active theme, relevant email extensions, and the WooCommerce version being evaluated. Avoid beginning a redesign from the warning text alone.
Check who maintains the file. A theme vendor may supply an update; a custom child-theme file may require your developer to restore deliberate changes onto a current base. WooCommerce's guidance explicitly recognizes both situations. Choose the path that matches the actual owner rather than copying a generic replacement recipe into production.
Save two references before changing anything
Keep a backup of the working template and capture a representative delivered email. The file preserves implementation details; the email shows the customer experience. Neither substitutes for the other.
Prepare a short record of intentional customization: logo placement, reading order, support wording, footer content, and any conditional sections. Separate those decisions from accidental behavior. A line break caused by an old layout is not necessarily something to preserve.
In Migma, retain an approved visual reference for the desired result. If the original creative exists there, identify the exact email. If it does not, create a review draft from approved copy and a permitted reference. Describe sample order facts as examples, so nobody mistakes a visual mockup for a source of live transaction data.
Reconcile implementation and creative separately
WooCommerce's official process calls for identifying outdated templates, saving backups, starting from the current default, and restoring customizations. Your developer should review the relevant differences and maintain the template through the store's established development process.
Do not resolve the warning by changing a version label while leaving the implementation unreviewed. The point is to understand and incorporate the actual changes. Likewise, do not replace a PHP template with a downloaded HTML design and assume the store will retain its data, hooks, and conditional behavior.
Migma's export documentation describes downloading HTML for other tools and reviewing the result in its destination. Use that HTML as creative input where the implementer finds it appropriate. The WooCommerce template and extension system still determine how order facts enter the message.
Build acceptance around difficult orders
A single tidy preview is a weak acceptance sample. Agree on a small set of representative cases before the developer starts. Choose cases from the notification's real purpose, rather than trying to exercise every store feature in one email.
| Sample case | What the reviewer should inspect |
|---|---|
| Several items with long names | Product text remains readable and totals are easy to locate |
| Missing optional customer detail | No empty label or awkward greeting appears |
| Discount and shipping charges | The message reflects the store's calculated facts |
| Relevant order-state change | The heading and next action describe that state accurately |
| Narrow screen and images blocked | Essential order meaning and support access remain understandable |
These are suggested review cases, not reported test results. Do not change an order's actual facts to make the layout look cleaner. If the notification does not contain a field, remove that case rather than inventing a new platform capability.
Compare the implemented result with the approved draft
Run Migma Email Preflight on the creative draft to review layout, links, writing, and common sending risks. Then inspect the implemented WooCommerce message separately through the team's approved test process.
Compare meaning first: notification purpose, customer name behavior, order reference, item details, totals, and the support action. Compare appearance next: logo, spacing, contrast, heading hierarchy, and button readability. A decorative difference may be acceptable; a changed payment or shipping promise needs an owner to resolve it.
Review the real delivered result in relevant inboxes when the team performs testing. A browser preview does not establish what every email client displays, and Preflight cannot promise inbox placement. Retain evidence of the accepted implementation with the corresponding source version.
Make the next update easier to review
Keep the customization record close to the template's maintenance instructions. Note who owns the code, who approves customer wording, where the Migma reference lives, and which sample cases were accepted. Avoid a handoff that consists only of a screenshot in a chat.
If a new default already meets the store's needs with supported settings, ask whether the custom override is still necessary. That is an implementation decision for the store owner and developer, supported by the approved creative requirements.
For broader redesign work, use the WooCommerce order-email review guide. For an update, keep the goal narrower: reconcile the changed template, preserve intentional brand decisions, and approve the actual customer message before release.
Frequently Asked Questions
Does Migma automatically update WooCommerce overrides?
No such native update workflow is established here. Use Migma for the approved creative and HTML handoff where appropriate; your WooCommerce developer owns the store template and its behavior.
Should I only change the template version number?
That does not demonstrate that changed implementation requirements were reviewed. Have the developer reconcile the current template with the intentional customizations and test the resulting notification.
What should I keep before updating an email template?
Keep a backup of the working implementation, a representative delivered message, the deliberate customization record, and the approved creative reference. Record the owner and version for each.
Is a correct browser preview enough to approve the update?
No. Review representative order facts and conditions in the implemented notification, then inspect the actual delivered result through the team’s approved testing process. Appearance alone does not establish correct behavior.