Moving Between Mail Apps: Record the Account Details You’ll Need

Start with the account identity

Write down the complete email address you use to sign in, including the part after the @ symbol. If you send or receive mail through additional addresses, list those separately and label what each one is for. An alias is not automatically a separate mailbox or login, so don’t assume it has its own password or independent storage.

Record the account provider and the official place to manage or recover the account. For BITTU Mail, the public website is bittumail.tech; sign-in, registration, account recovery and account actions go through mail.bittuicloud.com. Use the account’s official recovery process if you cannot confirm access, rather than guessing credentials in a new app.

• Full mailbox address: [name@example.com]
• Other sending or receiving addresses: [list and label]
• Official sign-in or recovery location: [verified address]

Make a settings card, not a password list

For each account, capture the incoming and outgoing server names, ports, encryption method, authentication requirement and username format. Also note whether the app requires the full email address as the username. These details are easy to misremember, and a correct server name with the wrong security option can still prevent a connection.

For BITTU Mail, the published IMAP settings are mx1.bittuicloud.com on port 993 with SSL/TLS. SMTP uses the same host on port 465 with SSL/TLS or port 587 with STARTTLS, and requires authentication with the full mailbox address as the username. Port 25 is not for a mail app. Never accept a certificate warning to force a connection.

• Confirm each value using current official provider information.
• Do not copy settings from an old device without checking them.
• Keep the password in an appropriately protected password manager, not in an ordinary migration checklist.

Account: [name@example.com]
Incoming: IMAP, mx1.bittuicloud.com, 993, SSL/TLS
Outgoing: SMTP, mx1.bittuicloud.com, 465 SSL/TLS or 587 STARTTLS
Outgoing authentication: required; username is full mailbox address
Password: not written here

Map the folders you rely on

List the folders you use and what belongs in them: for example, a project folder, sent correspondence, or messages you need to retain. Note any special organization, such as nested folders or rules that move incoming mail. This gives you a comparison point after setup, rather than relying on a vague impression that “the mail looks right.”

Folder names and organization may appear differently between clients. Check whether a folder is part of the mailbox or exists only inside the old app. A folder stored only on a device may not appear in another client simply because the account connects successfully. If you are unsure, consult the old app’s documentation or provider support before deleting its data.

• Important folders and approximate purpose: [name — purpose]
• Nested folders or special organization: [describe]
• Messages or folders that may be stored only on this device: [identify]

Note account and device dependencies

Record practical details that could affect the change: which devices use the account, whether another person or approved administrator manages it, and whether you use an additional sign-in step. Do not write down an OTP or share it with an assistant. If an administrator controls the mailbox or its policies, ask them to confirm what settings and access are available to your account.

For a work account, also note any approved sending restrictions or organization-specific requirements. Controls can depend on role, plan and provisioning state, so don’t assume a setting is available just because another account has it.

Set up and verify before removing the old client

Add the account in the new client using the verified settings. Then check more than the initial connection: confirm that recent messages appear, open a message you expect to find, inspect the important folders, and send a test message to an address you control. Reply to that message and verify that the response arrives in the expected account. These checks confirm basic access and sending; they do not guarantee how other providers will display or route future messages.

If setup fails, compare each field with the official settings again, including the encryption method and username. Do not bypass a certificate warning. Keep the old client available until you have checked the messages and folders you need and can access the account through the new setup.

A compact handoff example

A careful migration note might say: “Mailbox [name@example.com]; alias [sales@example.com] is an address, not a separate login; IMAP and SMTP values verified from the provider’s current official information on [date]; important folders are [Projects], [Receipts] and [Sent]; confirm these and send a test message before removing the old app.” Leave passwords and one-time codes out of the note.

After setup, mark each check complete only when you have observed it: account connects without a certificate warning, expected folders and messages are accessible, and a sent test message can be received and answered. If anything is missing, pause the cleanup and resolve the discrepancy first.