Use Migma as the reference for the email your team approved. After exporting to Klaviyo, compare that reference with the actual populated template. Approval should cover the version customers will receive, including destination-specific changes that were not visible on the original canvas.
A screenshot is useful for recognizing the design, but cannot prove that a button opens the right page or that a missing name gets a natural fallback. A template can also preserve the overall appearance while changing one sentence, offer condition, or footer action.
Migma’s export documentation explicitly calls for checking the destination version. The review below creates a practical acceptance record for that handoff. It is a workflow for one email, separate from migrating an entire account or choosing an email testing tool.
Freeze the approved reference
Give the email a recognizable version label and keep the reviewed source available. Record its intended purpose, subject, preview text, important claims, action destinations, and any approved content variations. Save the screenshot as a visual aid alongside those facts.
Avoid approving a moving target. If someone edits the Migma source after export, decide whether to re-export and review again or keep the destination tied to the earlier approved version. A timestamp alone is less useful than a note explaining what changed.
For an original example, imagine a workshop invitation with one registration button and a short eligibility sentence. That sentence may look minor beside the hero image, but it changes who the invitation is for. It belongs in the acceptance record.
Compare in three passes
First, compare meaning. Read the opening, offer, supporting details, and action. Confirm that no approved condition disappeared during shortening or adaptation. Check visible copy inside images and the subject/preview pair as well as body text.
Second, compare behavior. Review every important link in the final template, not just its button label. Confirm that tracking redirects preserve the intended destination and that required preference or unsubscribe actions use the destination platform’s supported implementation.
Third, compare rendering. Check the final populated message at desktop and narrow sizes and in the inboxes that matter to your audience. Look at reading order, contrast, wrapping, buttons, image crop, and whether a long value pushes essential content out of place.
Beefree’s email testing article is useful background on the range of things that can fail during final QA. Use your own approved source and audience requirements to decide what acceptance means for this email.
Record differences by their consequence
| Difference found | Question to answer | Suggested disposition |
|---|---|---|
| Font substitution | Is the text readable and the hierarchy clear? | Accept if it meets the approved purpose |
| Button destination changed | Does it still perform the promised action? | Resolve before approval |
| Personalization missing | Is an approved fallback shown? | Fix or remove the dependency |
| Eligibility sentence omitted | Has the offer’s meaning changed? | Restore or obtain new approval |
| Decorative spacing differs | Does it affect reading or tapping? | Review in context |
These are editorial acceptance suggestions, not an independent rendering benchmark. Define your own must-pass conditions before looking at minor visual differences.
Use examples that exercise the template
Preview a normal case, a long-content case, and a missing-optional-field case. If the message uses event data, ask the Klaviyo owner to confirm the actual sample and field mappings. A beautiful preview with hand-entered values does not prove the production data path works.
Check whether required actions depend on a value that can be absent. A fallback should preserve the reader’s next step or explicitly hold the message according to the owner’s rule. An empty link or a literal template token is a failed review.
Keep test information fictional or suitably minimized in shared records. Reviewers need to see the behavior, not a full customer profile. The owner should retain any sensitive operational evidence in the appropriate restricted system.
Keep the export mode visible
Migma offers an HTML handoff to Klaviyo and a beta editable adaptation route. Its current documentation describes layout and language constraints for those paths. Choose the route that supports your actual email, and inspect the result instead of assuming both produce identical native editing behavior.
If an editable adaptation changes the design materially, bring the difference back to the person who approved it. If HTML better preserves the required layout, use that supported option. Neither route removes the need to review variables, sender details, audience, and timing in the destination.
Migma’s compatibility guidance also explains that inboxes can render small differences. The goal is a stable, readable message with working actions. Do not promise pixel-identical output or guaranteed inbox placement.
Close the handoff with an actual decision
Record which template was checked, which source it matches, which examples were reviewed, and which differences were accepted. Include the reviewer and date. If a required condition failed, identify the owner and keep the campaign from proceeding until it is resolved.
Exporting a template does not send it. The sending owner makes the final audience, sender, and schedule decision after this review. For the next email, reuse the acceptance questions while replacing the source and destination evidence. That gives approval a clear object each time, rather than treating an old screenshot as permission for whatever version happens to be open.
Frequently asked questions
Does an approved screenshot prove an export is ready?
No. It helps visual comparison, but reviewers also need the actual template, populated values, working destinations, and final sending details.
Must the exported email look pixel-identical in every inbox?
No. Clients can render differently. Define required readability, layout, content, and action behavior and check the relevant inboxes.
What if someone edits the source after export?
Decide whether the destination remains tied to the earlier approved version or needs another export and review. Record that decision explicitly.
Does exporting to Klaviyo send the campaign?
No. Export creates a handoff. Review the populated destination and approve the audience, sender, subject, and timing separately.