What to Verify When Read, Starred and Flagged Mail Moves

Treat the message and its status as separate things

A message has content and identifying details—such as sender, subject and date—and it can also have a state. Read or unread describes whether it is marked as seen. A star often marks a message for attention. A flag may be a separate follow-up marker, sometimes with a colour or other meaning. Do not assume that a star and a flag are interchangeable just because both help you find mail.

During migration, the message may copy successfully while one or more of these states are omitted, translated into a different marker, or displayed differently by the destination app. The result depends on the source, destination and migration method. Even when both apps use familiar labels, matching labels do not prove they store or interpret a state in the same way. Treat each state as something to verify, not something guaranteed by message presence.

• First compare whether the message exists; then compare its read/unread state, star and flag separately.
• Note whether a marker is visible in the message list, in the opened message, or both.

Choose a sample that can reveal differences

Use a small sample that covers the kinds of mail you rely on, rather than checking only the newest messages. Include a few messages you know are read, a few you know are unread, some starred messages, and some flagged messages if your old app distinguishes flags from stars. Include messages from more than one folder if those folders matter to your workflow.

Write down enough detail to find each message again: folder, sender, subject and approximate date. Avoid relying on a sender name alone, since names can repeat. If a message is important, include it deliberately, but do not use a handful of successful checks as proof that every message or state migrated perfectly.

Sample record
Old app: Inbox | sender: [name] | subject: [subject] | date: [date]
Expected: unread, starred, not flagged
New app: found in Inbox | unread: yes | starred: yes | flagged: no

Compare one message at a time

For each sample, locate the message in the original app and the migrated mailbox. Match the subject and sender, then check the date and folder to avoid comparing two similar messages. Record whether the message is present before judging its status. If it is absent from the expected folder, search the destination mailbox before concluding it did not transfer; it may have been placed elsewhere.

Next, compare read/unread, star and flag as separate observations. Do not open an unread message in the destination if opening it could mark it as read before you have recorded its state. If you do open it, note that you changed the state during checking, then decide whether to restore the intended state. A status mismatch is worth recording even if you can correct it manually.

• Use a simple table with columns for expected state, observed state and action needed.
• Repeat the same checks for every item in your sample; do not rely on memory.

Check how your apps label and display markers

For a BITTU Mail mailbox, IMAP access uses mx1.bittuicloud.com on port 993 with SSL/TLS. That connection detail does not guarantee that another app’s stars, flags or read states will map exactly to BITTU Mail. If you connect an app, never accept certificate warnings; compare the states in the apps you actually intend to use.

Resolve important differences before relying on the mailbox

When the sample reveals a mismatch, decide what the message needs from you. A read/unread difference may matter if unread mail is your reminder system; a missing star or flag may matter if it marks follow-up. You can correct the destination state manually where the app provides that control, or keep a separate short list of unresolved items while you investigate the migration method.

Then check the changed message again in the destination, and, if you use more than one app, confirm the state in the app you plan to use day to day. A correction in one view is not evidence that every connected app will display it the same way. Keep the original mailbox available until the important sample has been reviewed and remaining differences are understood.

• Mark each sample item as matched, corrected, or unresolved.
• Recheck corrected items in the intended everyday app before you consider the check complete.

Make the check repeatable

Use the same sample record whenever you repeat the review: identify the message, write the original states, record what the destination shows, and note any change you made. If you migrate another folder or run another copy, compare the same records again and add a few messages from the new material. This helps reveal whether a difference is consistent without treating a small sample as a guarantee for the whole mailbox.

You can trust the migration more responsibly when you know which messages are present, which states match, and which exceptions remain. If exact state preservation is essential, verify it against your own source and destination rather than assuming that a familiar icon means the same thing in both apps.