Email Migration Tools: 7 Essential Steps to Prevent Website Migration Downtime

What would happen if your website moved successfully, but your customers and employees suddenly couldn't reach you by email? 

Email migration tools can help transfer your messages, but keeping business communication running takes more than copying mailboxes.

Google advises that new MX records—the settings that direct incoming email—can take up to 72 hours to be recognised. 

That doesn't mean three days of inevitable downtime, but it shows why timing, testing and keeping your existing service available matter. 

For some businesses, website hosting and email are completely separate. 

For others, they share the same package. 

Change the wrong settings or cancel that package too early, and you could interrupt recruitment conversations, customer enquiries and everyday employee communication.

The tricky part? 

Your new website might look perfectly fine while those problems happen behind the scenes.

In this guide, you'll learn whether your email actually needs to move, how to choose suitable email migration tools, and which checks to complete before switching. 

We'll walk through seven practical steps to protect your messages, prepare employees, test essential workflows and handle problems—so you can approach your website migration with a clear plan.

Your website can move successfully while your email stops working

So your new website loads, the pages look right, and everyone thinks the migration is finished. 

Then someone asks why customer emails have stopped arriving.

Moving your website can mean faster pages, better support and more flexibility. But your email may depend on settings or services that change during the move. If nobody checks those connections, a successful website launch can still leave your business struggling to communicate.

Here's the distinction: moving existing messages and delivering new emails are two separate jobs. An email migrator transfers mailbox data between supported systems. 

MX records tell sending servers where to deliver incoming email. 

Copying every message successfully doesn't prove that new messages will reach the right inbox. 

For example, your team might transfer its mailboxes correctly but leave incoming mail pointing to the old provider. Or someone might cancel the previous hosting package without realising it still runs the company's email.

Before calling the migration complete, assign someone to check that:

• External messages arrive in the correct inboxes.
• Employees can send emails and receive replies.
• Shared addresses, such as recruitment and support, still work.
• Website forms deliver their notifications.
• Any mailbox transfer errors have been investigated.

Treat email continuity as its own part of the migration plan, with a named owner and clear completion checks. The website going live is one milestone; keeping your business conversations flowing is another.

First, are you moving the website, the email—or both?

Before choosing email migration tools, ask a simpler question: what actually needs to move?

Your website and business email may use the same domain name, but that doesn't mean they run on the same service. Your website could sit with one hosting company while Microsoft 365 or Google Workspace handles your email.

In that situation, changing website hosts may not require a mailbox migration. The priority is to preserve the settings and services your email already depends on.

Things get more complicated when your hosting package includes both. 

Cancelling the old package could remove more than website files—it could also close mailboxes your employees still use.

Use this table to identify what your move involves:

The practical rule is straightforward: don't move working email just because you're moving your website. 

First, establish whether the existing email service can stay in place. 

Draw a simple map before changing anything

You don't need a complicated technical diagram. 

A shared document showing which provider handles each service is a useful starting point.

Record the following:

• Domain registrar and renewal owner: Where is the domain registered, and who makes sure it stays renewed?
• DNS provider: Where are the records that direct website traffic and email managed?
• Website host: Which service stores and runs your website?
• Email provider: Where do employee mailboxes, shared inboxes and aliases live?
• Website forms and transactional email: What sends contact enquiries, order confirmations and password-reset messages?
• Administrative access and recovery methods: Who can access each service, and how will they recover access if business email is unavailable?

Keep passwords and recovery codes in an approved password manager rather than placing them in this shared document.

For example, your domain might be registered with one company, your DNS managed through Cloudflare, your website hosted elsewhere and your email handled by Microsoft 365. 

Mapping those connections helps your team identify exactly what must change—and what needs to keep working throughout the move.

Before proceeding, make sure every service has a named owner and nobody is relying on the hosting package you're about to cancel.

How do you choose email migration tools that fit your setup?

 The right email migration tools depend on what you're moving, where it's going and what your employees need to keep working. Start with those requirements before comparing product names.

For example, moving a handful of mailboxes between business email providers is a different project from transferring an organisation's shared inboxes, calendars, contacts and archives. A tool that handles the first job may not cover the second.

Before choosing an email migrator, check these six areas:

• Supported source and destination: Does it support your exact combination of existing and new email systems?
• Data coverage: Will it transfer the messages, contacts, calendars and shared mailbox data you need?
• Follow-up synchronisation: Can it copy messages that arrive after the initial transfer, and under what conditions?
• Error reporting: Can you identify failed or skipped items, understand the cause and retry them?
• Authentication and permissions: What access does the tool require, and how will you remove temporary permissions afterwards?
• Data handling, support and cost: Where is data processed, what help is available, and what will licences, administrator time and additional services cost?

Write down what a successful migration must include. "All employee email moved" sounds clear until someone discovers that shared calendars or mailbox permissions weren't part of the transfer.

When should you consider a third-party tool?

A third-party tool is worth assessing when your requirements go beyond what the native route supports—or when its reporting and migration workflow would make the project easier to manage.

That could include:

• Moving accounts from several different email systems.
• Transferring additional supported workloads alongside mail.
• Needing more detailed progress reports and exception handling.
• Organising transfers in batches with follow-up passes.
• Requiring specialist migration support.

BitTitan MigrationWiz is one option to investigate for supported mailbox migration projects.

Confirm the exact source and destination, licence requirements and workload coverage before selecting it. Treat vendor claims as claims to evaluate through documentation and a pilot. 

Here's a practical starting point for your comparison: 

The last option deserves consideration.

If your email service already meets your needs, keeping it in place could reduce the scope of the website migration.

Don't assume every tool moves everything

"Supports email migration" doesn't tell you enough to approve a tool.

For example, Microsoft's documented IMAP migration route transfers messages in inboxes and other mail folders, but doesn't migrate contacts, calendar items or tasks. 

A completed mail transfer could therefore leave employees without information they expected to find. 

Imagine your HR team opens its new mailbox and finds every recruitment email—but none of its interview appointments. The messages have moved, yet the team's working day is still disrupted.

Before committing, run a pilot using accounts that reflect how your organisation works. Include a larger mailbox and, where relevant, a shared inbox or delegated account. 

Check the results against your requirements and record anything that needs a separate transfer.

Choose the tool that passes your checks, rather than the one with the longest feature list.

Your website migration checklist: 7 essential steps to protect business email

A smooth migration starts before anyone changes a setting. 

You need to know what depends on email, who owns each task and how you'll confirm everything works afterwards.

Use these seven steps to turn those questions into a practical plan. If you're only moving your website, some mailbox transfer tasks may not apply—but the dependency checks and delivery tests still matter.

Step 1 — Find every mailbox and business process that depends on email

Owner: IT lead, supported by department managers.

Start by looking beyond individual employee inboxes. Your business may rely on shared addresses, automated messages and devices that nobody immediately associates with the website.

Create an inventory covering:

• Employee mailboxes, aliases and shared inboxes.
• Recruitment, payroll, support and sales addresses.
• Forwarding rules, distribution lists and delegated access.
• Website forms, CRM notifications and password-reset messages.
• Printers, scanners and other applications that send email.

Ask department managers what happens when each service stops working. A missing sales notification could delay a response, while a failed welcome message could interrupt customer onboarding.

Deliverable: A shared inventory showing each mailbox or application, its provider, its business purpose and its owner.

Completion check: Every critical address and sending application has a named owner who can help test it.

Step 2 — Protect your data and record the current configuration

Owner: IT team or managed service provider.

Before changing anything, document how the existing setup works and how you would recover it. 

Screenshots can help, but keep an export of the configuration where available.

Your preparation should include:

• Exporting the DNS zone and recording existing settings.
• Confirming mailbox backup and recovery arrangements.
• Checking destination storage capacity and licences.
• Recording retention, archive and any legal hold requirements.
• Preserving administrative access to the old service.
• Identifying data or settings that won't transfer automatically.

Keep credentials and recovery codes in an approved password manager, with access restricted to the people who need them.

Also check what cancelling the old hosting package would remove. It may contain mailboxes, forwarding services or application settings that still support the business.

Deliverable: A saved configuration, documented recovery arrangements and a list of migration exclusions.

Completion check: The team can explain how it would recover from a failed transfer or configuration change.

Step 3 — Choose the migration method and run a pilot

Owner: Migration administrator.

First, confirm whether mailbox data needs to move at all. If email is staying with its existing provider, focus on preserving its dependencies and testing delivery.

Where a transfer is necessary, choose email migration tools that support your exact source, destination and required data. 

Then test the approach with representative accounts before committing the whole organisation.

During the pilot:

• Include different mailbox sizes and usage patterns.
• Test a shared mailbox or delegated account where relevant.
• Check folders, attachments and any supported permissions.
• Verify contacts and calendars if they're within scope.
• Review failed, skipped and excluded items.
• Confirm how follow-up synchronisation works, where supported.

Remember that migration methods have different limits. Microsoft's IMAP migration route, for example, transfers mail folders but not contacts, calendar items or tasks. 

Deliverable: A pilot report showing what transferred, what failed and what needs separate handling.

Completion check: The pilot meets your documented requirements, and every outstanding exception has an agreed response.

Step 4 — Prepare DNS and email authentication

Owner: DNS administrator and email administrator.

DNS settings help other systems find your website and deliver your email. Changing nameservers or replacing a DNS zone can affect both, so review the proposed changes carefully.

Here's what the main email-related settings do:

Cloudflare provides documentation covering email routing and authentication records. Follow the instructions for your actual email provider and DNS service rather than applying a generic configuration. 

For a website-only move, preserve the mail-related configuration that remains valid. For an email provider change, prepare the destination accounts and authentication settings before switching routing.

If your plan involves lowering TTL values, do so sufficiently in advance for previously cached answers to expire. A last-minute change won't clear existing caches.

Deliverable: A reviewed DNS change plan showing which records will change, which will remain and how problems will be handled.

Completion check: The proposed changes have been compared with the saved configuration and approved by the responsible administrators

Step 5 — Tell employees what will happen and where to get help

Owner: Internal communications, supported by HR and IT.

Employees shouldn't have to guess whether an unexpected sign-in prompt or missing message is part of the migration.

Publish a short, practical notice explaining:

• When the migration will happen, including relevant time zones.
• What disruption employees might experience.
• Whether passwords, sign-in methods or device settings will change.
• What employees need to do before and after the move.
• Where to report problems.
• Which backup communication channel to use.
• How to verify unexpected requests for credentials.

Put the instructions somewhere employees can reach if email is unavailable. An intranet can help, provided its access doesn't depend on a service affected by the migration.

For frontline, remote and shift-based teams, make sure the notice reaches people who may miss a normal office-hours announcement.

Deliverable: An employee migration notice, accessible instructions and a tested support route.

Completion check: Employees can find essential guidance and contact support without relying on the email service being changed.

Step 6 — Make the change and test real work

Owner: IT lead, supported by business testers.

Once the readiness checks pass, carry out the agreed changes and test complete workflows. 

A migration dashboard showing "completed" is useful, but it doesn't tell you whether HR can receive applications or customers can contact support.

Test the following:

• Incoming and outgoing messages with external accounts.
• Internal messages between employees.
• Replies, attachments, aliases and shared inboxes.
• Desktop, browser and mobile access.
• Website contact forms and their notifications.
• Recruitment and customer support workflows.
• Password resets and other application-generated messages.
• Message headers, authentication results and delivery logs.

Record the sender, recipient, time and result of each test. If a message fails, use the logs to investigate rather than repeatedly sending it and hoping it arrives.

Ask business owners to test the processes they actually use. For example, submit a website enquiry and check that it reaches the correct inbox and can receive a reply.

Deliverable: A test record covering mail delivery, employee access and critical business workflows.

Completion check: Named business owners confirm that their essential processes work, with unresolved failures escalated before sign-off. 

Step 7 — Reconcile the results before retiring the old service

Owner: IT lead and business sponsor.

Keep the old service available until you've checked the data and confirmed reliable delivery. 

Avoid cancelling it simply because the new website is live or the initial mailbox copy has finished.

Before retiring it:

• Review failed, skipped and missing migration items.
• Complete supported follow-up synchronisation.
• Investigate messages still arriving in the old system.
• Reconcile data received by either system during the transition.
• Confirm retention, archive and recovery arrangements.
• Resolve user issues or formally accept documented exceptions.
• Remove temporary migration permissions and credentials.
• Obtain approval before cancelling the old service.

Returning DNS to its previous configuration does not automatically reconcile messages received by two different systems. Your recovery plan must address those messages as well as routing.

Deliverable: A reconciliation report, completed issue log and recorded approval to retire the old service.

Completion check: Data, delivery and access meet the agreed acceptance criteria, and the business sponsor approves closure.

Download your website and email migration checklist

Planning a website move? 

Use this practical checklist to map your email dependencies, compare migration options, prepare DNS changes and test essential workflows. 

It includes responsibility prompts, completion checks and a final sign-off section to help your team confirm when it's safe to retire the old service.

What happens when something goes wrong?

 You've made the switch, but something isn't working. 

Perhaps employees can send messages but receive nothing back, or your website contact form says "submitted" while the enquiry never reaches your team.

Start by identifying which part of the process has failed. Mailbox data, incoming delivery, outgoing messages and employee access are separate checks. 

A problem with one doesn't necessarily mean the entire migration has failed.

Use this table to narrow down your investigation:

Is it a DNS delay or a configuration problem?

DNS changes aren't always recognised everywhere immediately. Google advises that new MX records can take up to 72 hours to be recognised. That is a planning allowance—not a prediction that your business will lose email for three days. 

However, don't assume every delivery failure will fix itself with time. Waiting won't correct a missing mailbox, an incorrect MX destination or invalid sending credentials.

Ask your administrator to compare the live configuration with the approved migration plan. Keep the old service available while they investigate, and record failed tests with timestamps, sender and recipient addresses, and any error messages.

If a critical workflow fails, follow your agreed escalation or recovery plan. 

Avoid making several untracked changes at once: each change should have a clear purpose, an owner and a test that confirms whether it worked. 

Who should own the migration—and who needs to be involved?

Give one person overall responsibility for the migration, with named owners for each supporting task. 

That will usually be your IT Director, IT lead or migration project lead.

They should coordinate the plan, confirm technical readiness and decide whether the switch can proceed. But they'll need input from the people who understand how email supports everyday work. 

IT can check delivery logs; HR can confirm that recruitment messages arrive; customer support can test its shared inbox.

Use this responsibility table to make those expectations clear:

Make the handoffs clear before migration day

 Job titles alone won't prevent confusion. Record who will make each change, who will check the result and who can authorise recovery action if a critical test fails.

For example, the email administrator might confirm that a recruitment mailbox receives messages. The HR lead should then check that the team can open applications, reply to candidates and access the shared inbox as expected.

HR's role is to identify employee needs and validate its workflows. Technical DNS changes belong with the administrators responsible for those systems.

In a smaller business, one person or an external IT provider may cover several roles. That's fine—what matters is that every responsibility has an owner, and everyone knows who makes the final decision.

A realistic example: the new website launches, but recruitment goes quiet

 Imagine a business moving its website to a new hosting provider. The new site launches successfully, so the team cancels the previous hosting package.

What nobody checks is that the old package also contains the company's recruitment mailbox.

The next morning, candidates struggle to contact HR. Interview confirmations stop arriving, and the recruitment team cannot access its usual inbox. With interviews approaching, employees start using personal email accounts to keep things moving.

A website upgrade has now created an operational problem—and scattered candidate conversations across accounts the business doesn't manage.

What should have happened?

Before cancelling the package, the migration lead should have worked with HR to:

• Identify the recruitment mailbox and its hosting provider.
• Decide whether to retain that service or transfer the mailbox.
• Confirm that required messages and other data remain accessible.
• Test incoming messages, replies and shared access.
• Keep the old service available until the checks pass and retirement is approved.

The HR team didn't need to understand every technical setting. It needed an opportunity to identify a critical dependency and confirm that recruitment could continue.

A successful launch means people can still do their jobs—not just that the homepage loads. 

Protect employee trust while accounts and access are changing

 A migration can bring unfamiliar sign-in screens, setup instructions and requests to reconnect devices. 

Employees need a clear way to distinguish legitimate changes from suspicious messages.

The UK government's Cyber Security Breaches Survey 2025/2026 found that phishing affected 88% of businesses that identified a cyber security breach or attack during the previous 12 months. 

That figure describes affected businesses, not all businesses, and does not measure migration-related incidents. It provides useful context for taking credential requests seriously during a change. 

Before the migration, explain who will contact employees, where approved instructions will appear and how they can verify a request through a known support channel.

Your security preparations should also cover:

• Credentials: Use approved methods for granting migration access. Keep passwords and recovery codes out of ordinary email threads and shared documents.
• Migration exports: Restrict access to exported mailbox data and use approved storage and transfer arrangements.
• Administrative permissions: Give the migration team the access required for the chosen method, with clear ownership and oversight.
• Authentication: Follow provider-supported authentication requirements and plan MFA or device changes before the cutover.
• Temporary access: Remove migration accounts, tokens and permissions when they are no longer needed.
• Retention and deletion: Document which copies must be retained, who can access them and when temporary data should be deleted.

Make it easy for employees to report something unusual without feeling they are holding up the project. 

A quick verification is more useful than someone guessing whether a password request is genuine.

Keep migration updates somewhere employees can still reach

 If email becomes unavailable, an update sitting in everyone's inbox won't help much.

Prepare a central information page before migration day and show employees how to reach it. Keep the content short, current and focused on what they need to do.

Include:

• The migration schedule, with relevant time zones.
• Progress announcements, including what has changed and when the next update is due.
• Device setup instructions for affected desktop and mobile users.
• Known issues, with available workarounds.
• Support contacts and a clear escalation route for urgent problems.

AgilityPortal can give employees one place to find migration updates, instructions and support information, helping teams stay informed while IT manages the technical work. Department managers can also direct their teams to the same guidance, reducing conflicting instructions.

Test access before relying on it. If the intranet uses an identity service affected by the migration, employees could lose access to that channel too.

Prepare an independent fallback, such as a separately accessible status page or an approved telephone support route. Share those details in advance so employees know where to turn if their usual tools stop working.

Build a repeatable process for the next workplace technology change

Once the migration is complete, turn what you learned into a process your team can reuse.

The same preparation can help when changing your CRM, employee intranet or other workplace systems.

Start with a service dependency register: a shared record of which systems rely on each other. Include providers, named owners, connected applications and recovery arrangements. Update it whenever a service changes, rather than waiting for the next project.

For future email migration planning, keep these resources alongside your internal checklist:

• Microsoft's IMAP migration guidance to check the scope and limitations of that migration method.
• Google Workspace's data import documentation to assess supported email sources.
• Cloudflare's email DNS configuration guide to support reviews of mail routing and authentication records.

These references help administrators check requirements against provider documentation rather than relying on an old project plan. 

Keep the useful parts—and measure what needs improving

Save your tested employee notices, support instructions, cutover checklist and acceptance criteria as reusable templates. 

Train employees to recognise approved change notices, and maintain a backup communication channel that remains accessible if the main service fails.

Then review a small set of business continuity and migration performance metrics: 

Record the lessons, assign owners to outstanding improvements and keep recovery details current. 

The next technology change should start with a tested plan your team understands.

Final Thoughts: protect the conversations your business depends on

A website migration should leave your business better connected. 

That starts with understanding how your website, email hosting, DNS and everyday applications work together—and checking those connections before making changes.

Email migration tools can help move mailbox data, but they're only one part of a successful transition. Your team still needs to verify delivery, test essential workflows, prepare employees and confirm when it's safe to retire the old service.

Before your next move, bring IT, HR and department owners together around one practical checklist. Agree what must keep working, who will test each process and what evidence you need before signing off. 

Keep instructions accessible and make sure employees know where to get help if their usual communication channels fail.

You don't need to move every service at once. You need a clear reason for each change and a reliable plan for managing it.

The real measure of success is that customers can reach you, employees can do their jobs, and important conversations carry on.

Frequently asked questions

1. Are there any free email migration tools?

Yes, free email migration tools and provider-included migration options are available. However, check what "free" covers: destination subscriptions, storage, technical support and administrator time may still cost money. Confirm that the tool supports your email systems and required data before using it. 

2. Which email migration tools work with Microsoft 365?

Email migration tools for Microsoft 365 include Microsoft's native migration routes and compatible third-party products. The right choice depends on your existing email system, mailbox requirements and migration scope. Check the specific method's prerequisites rather than assuming every route transfers the same data. 

3. What are the best email migration tools for a business?

 The best email migration tools support your source and destination, transfer the data you need and provide useful error reports. Compare authentication, follow-up synchronisation, support and total cost. Run a pilot with representative mailboxes before choosing a tool for the whole organisation.

4. Are the top 10 cloud migration tools suitable for email migration?

 Not necessarily. Lists of the top 10 cloud migration tools may focus on servers, databases or applications rather than mailboxes. For business email, check explicit support for your email platforms, messages, folders and any required calendars, contacts or permissions.

5. How are email migration tools different from other data migration tools?

 Data migration tools move information between systems, but their supported workloads vary. Email migration tools specialise in mailbox content, while other products may handle databases, files or applications. A general data transfer tool isn't automatically suitable for preserving mailbox structure and email-specific information.

6. Can SharePoint migration tools move employee email?

Don't assume they can. SharePoint migration tools generally focus on SharePoint content, such as documents and sites. A wider migration suite may offer separate mailbox functionality, but you should verify its email coverage and licensing. Treat SharePoint and mailbox transfers as distinct workloads. 

7. Does an Office 365 migration tool transfer contacts and calendars?

An Office 365 migration tool may transfer contacts and calendars, depending on the product and migration method. For example, Microsoft's documented IMAP migration route transfers mail folders but excludes contacts, calendar items and tasks. Check the exact scope before planning your move. learn.microsoft.com 

8. Should I choose an open-source email migration tool?

 An open-source email migration tool can be worth considering if your IT team can assess, configure and support it. Check maintenance activity, authentication compatibility, logging and data coverage. Open source doesn't remove the need for testing, secure credential handling or a recovery plan.

9. Do I need email migration tools when changing website hosts?

 Only if mailbox data also needs to move. If your email stays with its existing provider, you may simply need to preserve its DNS configuration and service dependencies. Before cancelling old hosting, confirm that it doesn't contain mailboxes or sending services your business still uses.

10. Can email migration tools prevent downtime and lost messages?

 Email migration tools can support a carefully planned transfer, but they don't guarantee uninterrupted delivery. Prepare destination accounts, check routing, test essential workflows and reconcile messages received during the transition. Keep the old service available until your agreed data, delivery and access checks pass.