Mailgun Migration: Review the Promised Attachment

An email that says “your document is attached” makes a specific promise. During a Mailgun migration, the message can look right while the file is missing, outdated, or associated with the wrong event. Review the attachment as part of the reader’s task, not as an incidental implementation detail.

Use Migma to prepare the reviewed email creative. Have the application and sending owners verify document selection, access, and the destination provider’s current attachment support. This guide does not establish that every Mailgun attachment workflow can move unchanged to Loops or another sender.

Inventory the promise before moving the send

Find messages that refer to an attachment in the subject, preview text, body, or support instructions. Include references such as “open the attached guide” even if the actual file is added somewhere else in the application. The creative alone may not reveal the full dependency.

Loops’ Mailgun migration guide describes mapping sending behavior and reviewing template-based workflows. Use that as discovery context. The attachment decision below requires verification against your actual source implementation and the current destination documentation; it is not an assertion of feature parity.

For each message, record the file’s purpose, how it is selected, the accepted version, filename, format, expected size range, and owner. Distinguish a static welcome guide from a recipient-specific statement. They have different review and access requirements.

Decide whether a file or a link serves the job

Do not silently replace an attachment with a link because a migration is easier that way. A recipient may need an offline copy, a stable record, or an authenticated portal. Ask the business owner which delivery method meets the actual need.

A link may be appropriate when the document changes frequently or requires access control, but then the email should describe that link accurately. An attachment may be appropriate for an accepted fixed document, but its identity and distribution still need review. These are workflow choices, not universal recommendations.

If the accepted delivery method changes, revise the Migma copy explicitly. “View your document in the portal” is a different promise from “your document is attached.” Update the subject and preview text too, because readers may act on those before opening the body.

Check the destination before promising a cutover

Ask the sending owner to verify current attachment capabilities, allowed formats, size limits, encoding requirements, and relevant plan restrictions in the destination’s official documentation. Record the date of that check. Do not reuse a limit from an old migration note or assume a raw SMTP workflow maps to a template-based API.

Have the owner identify where the file is produced and where it is attached. A template identifier and its dynamic fields may describe the email without carrying the document itself. The migration must cover both responsibilities if both are required.

If the required behavior is unsupported, preserve the current owner for that message type while the team evaluates an approved alternative. Do not declare the migration complete by removing the promised file from the test case.

Use a document acceptance matrix

A fictional training-guide email provides a low-risk rehearsal. Test the accepted guide, a newer unapproved draft, a missing file, and a filename containing spaces. Add realistic size and format boundary cases based on the destination’s verified limits.

Do not use confidential real documents merely to make a test feel realistic. Fictional files can exercise the delivery path without exposing customer information. Preserve private message references in your normal operational system.

Review the email and document together

Migma prepares editable email creative from approved context. Ask it for a clear document-delivery message with one main action and a support route. Supply only the facts needed to write the email; do not treat the drafting task as permission to upload sensitive source documents.

Run Email Preflight for links, wording, inbox previews, and delivery-risk warnings. Then inspect the actual final test message from the sending system. Open the file through your approved test process and confirm that its contents match the promise in the email.

A design preview does not prove an attachment was transmitted. Provider acceptance also does not prove the recipient can open or understand the file. Keep these pieces of evidence separate in the receipt.

Cut over one document purpose at a time

Name one owner for the intended send and reconcile queued work before moving responsibility. Avoid sending the same document from both providers as a makeshift comparison. Compare controlled test outputs first, then follow the team’s accepted rollout process.

Save the document identity, creative version, support check, test matrix, reviewer, and final-output evidence together. That record makes future template changes easier to review. Begin with the Migma message, but accept the migration only when the recipient’s promised document journey is complete.

Frequently Asked Questions