Changing your email provider does not necessarily mean moving your website. You can keep your domain and web hosting where they are while using a separate service for business correspondence. A well-planned email migration has two main goals: preserving existing data and checking that new messages reach the right destination. Treat mailboxes, messages, contacts, calendars and DNS settings as separate parts of the project.
1. List your mailboxes and find every place messages are stored
Before changing anything, create a list of the addresses your business uses. Include individual mailboxes, shared addresses such as office@, aliases, forwarding rules and distribution groups. An alias is not necessarily a separate mailbox, so you need to recreate what it does rather than simply copy its name.
- Record who uses each address and who needs access after the move.
- Check storage usage, folder structures and the new service's limits.
- List rules, filters, automatic replies and shared mailbox permissions.
- Identify applications that send email, including your website, online shop, forms, invoicing software and printers.
- Record where your domain is managed and where its DNS records are hosted.
Check users' computers as well. If someone uses POP or local archives, some messages may exist only on their device rather than on the server. These need an export or a separate import process. Do not assume that everything visible in an email application will be included in a server-to-server transfer.
Assign someone to coordinate the move, agree a working window and decide how colleagues will receive their new instructions. Avoid putting passwords in shared documents or sending them to mailboxes you are about to reconfigure.
2. Prepare the destination without moving your website
Create all the required mailboxes with the new provider before changing mail routing. Set up aliases, groups and delegated access, then check that users can sign in. Where supported, enable multi-factor authentication and prepare the authentication method required by your migration tool.
Website hosting and email hosting serve different purposes. If you are also considering web hosting, do not assume that an email move requires a website move. You can usually change the email-related DNS records while leaving the existing website records in place.
Save a copy of the current DNS configuration and identify exactly which records need updating. Do not change nameservers merely to update email routing unless there is a separate reason to do so. A nameserver change can affect your website and other services too.
Check message size limits, available storage and supported import methods. Create an independent backup using a method suitable for your services and applications, and check that you can access the exported data.
3. Copy messages and check the first IMAP synchronisation
An IMAP synchronisation tool can copy messages and folders from the old server to the new one. IMAP does not normally transfer contacts, calendars, passwords, rules or all account settings. The precise behaviour depends on the tool and both email services.
- Choose a representative mailbox for a trial, including older messages, attachments and nested folders.
- Connect the source and destination using secure connections and a supported authentication method.
- Run the initial copy without deleting messages from the source.
- Review the operation log and investigate skipped messages or errors.
- Once you have validated the trial, continue with the remaining mailboxes.
What to check in the copied messages
Compare message counts for individual folders, not just the mailbox total. Differences can come from hidden folders, labels converted into folders, duplicate messages or items rejected because of service limits. Matching totals are useful, but they do not prove on their own that the transfer is complete.
Open messages from different periods and check the sender, recipient, date, content and attachments. Inspect Sent, Drafts and Archive folders separately, along with read and unread status where the tool preserves it. Configure repeat synchronisation runs to limit duplicates and avoid propagating unwanted deletions.
4. Move contacts and calendars separately
Check the export and import options offered by both services for contacts and calendars. Contacts may be exported as CSV or vCard files, while calendars commonly use ICS. Compatibility is not perfect: custom fields, photographs and some event properties may need adjustments.
- Run a trial import and check names, email addresses, telephone numbers and accented characters.
- Check time zones, recurring events, exceptions and reminders.
- Review shared calendars and permissions separately, as these may need to be recreated.
- Distinguish autocomplete suggestions from the actual address book: they are not always the same set of data.
For meetings with attendees, check how the new service handles the organiser and future updates. Importing a calendar does not automatically transfer all rights associated with meeting invitations. Avoid sending invitations again in bulk without testing, and tell colleagues if particular meetings need to be recreated.
5. Change mail routing and configure outgoing email
After the initial copy and destination checks, update the MX records according to your new provider's instructions. These records determine where incoming email for your domain is delivered. If your schedule allows, reducing the TTL in advance may shorten how long DNS responses remain cached, but it does not remove every possible delay.
Configure the domain's authentication settings for outgoing email as well:
- SPF: update the existing policy to cover authorised senders; do not create several separate SPF records at the same DNS name.
- DKIM: publish the records specified by the new service and enable signing.
- DMARC: check domain alignment and make sure the policy works with all legitimate sending sources.
During the transition, some sending servers may still use cached DNS information. Keep the previous service active and run additional synchronisations to collect messages delivered there. Update users' email applications and your website's SMTP settings rather than assuming they will change when you update MX records. For general guidance, see the frequently asked questions.
6. Validate the transfer before closing the old service
Test sending and receiving with external addresses in both directions, and check internal communication separately. Include aliases, shared mailboxes, forwarding and website forms. Investigate delivery errors and inspect the SPF, DKIM and DMARC results in the headers of received messages.
- Confirm that public mail routing points to the new service and that test messages arrive there.
- Compare folders again and investigate any remaining differences.
- Run a final copy of new messages from the old service.
- Ask each user to confirm access to their messages, contacts and calendars.
- Keep the exports and document the final settings and resolved issues.
Do not close the old service simply because the first test worked. Check whether it is still receiving messages and decide when to cancel based on your observations, contractual terms and business needs. Once the migration has been accepted, revoke any temporary access granted to the tools you used.
The practical takeaway: take an inventory, copy your data, switch routing and validate the result before cancelling. To discuss your requirements in relation to GazduireOnline.ro services, use the contact page and provide the number of mailboxes, approximate data volume and applications involved, without sending passwords.
