A Microsoft 365 email migration for a small business with 10 to 25 mailboxes takes 4 to 8 hours for data transfer plus 1 to 2 weeks of preparation. The key to losing nothing is a three-phase approach: sync all mail before cutover, verify every mailbox after cutover, and do not touch the old system until verification is complete. Most migration failures happen because someone skips verification or misconfigures DNS records.
A Microsoft 365 email migration for a small business with 10 to 25 mailboxes takes 4 to 8 hours for the actual data transfer, plus 1 to 2 weeks of preparation. The key to losing nothing is a three-phase approach: sync all mail before cutover, verify every mailbox after cutover, and do not touch the old system until verification is complete. Most migration failures happen because someone skips the verification step or misconfigures DNS records.
That is the quick answer. Now let me walk you through exactly how we do this for businesses across Volusia County, including the specific DNS settings, the validation scripts, and the mistakes that cause data loss so you can avoid them.
Why Businesses Still Get This Wrong in 2026
Email migration should be simple by now. Microsoft has been offering migration tools for over a decade. Yet we still get calls from businesses in DeLand, Daytona Beach, and Ormond Beach who attempted a DIY migration and ended up with missing emails, broken calendars, or worse: emails going to a black hole because the DNS records were configured incorrectly.
The problem is not the migration itself. Moving mailbox data from one server to another is a solved problem. The problem is everything around the migration: DNS propagation timing, email authentication records, mobile device reconfiguration, and the gap between when you switch the mail flow and when every device on your network catches up.
Here is a real example. A property management company in DeLand tried to migrate their 15 mailboxes to Microsoft 365 over a weekend. They changed their MX records on Saturday morning, started the migration tool, and by Monday morning most of their email was flowing through Microsoft 365. But not all of it. Three mailboxes had errors that the migration tool reported but nobody checked. Those three people lost incoming email for two days because the old server was still receiving mail for their addresses while Microsoft 365 thought they were migrated. The emails sat on the old server, undelivered, until someone noticed the problem on Wednesday.
That scenario is entirely preventable with proper planning and validation. Here is how.
The 7-Step M365 Migration Process
Step 1: Inventory Your Current Email Setup
Before you touch anything, document what you have. This means every email address in your organization, every alias, every distribution list, every shared mailbox, and every forwarding rule. You also need to know your current email provider, your domain registrar, and who controls your DNS records.
Most small businesses we work with in Volusia County have between 5 and 30 mailboxes. The inventory takes 30 minutes for a simple setup and a few hours for organizations with shared mailboxes, distribution groups, and legacy aliases. But skipping this step is how you end up with missing addresses after migration.
Step 2: Purchase and Configure Microsoft 365 Licenses
Microsoft 365 Business Basic starts at $6 per user per month and includes Exchange Online for email, OneDrive for file storage, and the web versions of Office apps. Business Standard at $12.50 per user per month adds desktop Office apps. For most small businesses, Business Basic is sufficient for email migration, and you can upgrade later if you need desktop apps. For related strategies, check out Docker for IT Ops: Containerizing Your Internal Tools.
Create your Microsoft 365 tenant, add your domain, and create user accounts that match your existing email addresses. Do not change the MX records yet. At this point, Microsoft 365 knows about your domain but is not receiving email for it. That comes later.
One important detail: when creating user accounts, make sure the primary email address on each M365 account exactly matches the existing address. If someone’s email is [email protected], the M365 account must use that same address. Typos here mean mail gets delivered to the wrong account or bounces entirely. Also create any shared mailboxes, distribution groups, and aliases at this stage so they are ready when you migrate.
Step 3: Lower Your DNS TTL (24 Hours Before Migration)
This is the step that separates professional migrations from amateur ones. Your DNS records have a Time to Live value that tells other servers how long to cache the record. Default TTL is usually 3600 seconds (1 hour) or higher. Lower it to 300 seconds (5 minutes) at least 24 hours before your migration window. This ensures that when you do switch the MX records, the change propagates across the internet in minutes instead of hours.
If you skip this step, some email servers will keep sending mail to your old provider for up to 24 hours after you switch MX records because they cached the old records. During that window, mail is split between two systems, and you might not realize it until someone reports missing email on Monday.
Step 4: Configure Email Authentication (SPF, DKIM, DMARC)
This is where most DIY migrations go wrong. Email authentication is how receiving servers verify that email from your domain is legitimate. If you misconfigure these records, your outgoing email will be flagged as spam or rejected entirely.
SPF (Sender Policy Framework): Add a single TXT record to your DNS that tells the world which servers are authorized to send email for your domain. For Microsoft 365, the record is: v=spf1 include:spf.protection.outlook.com -all. Critical rule: you can only have one SPF record per domain. If you already have an SPF record from your old provider, merge it into a single record, do not add a second one. Multiple SPF records cause authentication to fail.
DKIM (DomainKeys Identified Mail): Microsoft 365 auto-signs email using its own onmicrosoft.com key, but this does not match your custom domain. You must publish two CNAME records in your DNS and then enable DKIM signing in the Microsoft 365 Defender portal. Without this, your emails will fail DMARC alignment checks at strict receiving servers, which means Gmail and other providers may quarantine or reject your messages.
DMARC (Domain-based Message Authentication): Start with a monitoring policy: v=DMARC1; p=none; rua=mailto:[email protected]. This tells receiving servers to send you reports about authentication failures without actually blocking email. After 2 to 4 weeks of monitoring, once you confirm that all legitimate email passes SPF and DKIM checks, tighten the policy to p=quarantine and eventually p=reject.
Step 5: Migrate Mailbox Data
Now comes the actual data transfer. For migrations from hosted Exchange or another Microsoft 365 tenant, use the built-in Exchange migration tools. For migrations from Google Workspace, Microsoft provides a Google Workspace migration tool that handles email, contacts, and calendars. For IMAP-based email providers (like GoDaddy email, Rackspace, or basic hosting providers), use the IMAP migration wizard — but be aware that IMAP only migrates email, not contacts or calendars.
Start with a pilot batch of 3 to 5 users. Migrate their mailboxes first and verify everything before migrating the rest. This catches configuration issues early when they affect a small group instead of your entire company.
The data transfer itself runs in the background. Microsoft pulls the data from your old server incrementally, so you can start the migration days before the actual cutover. The tool syncs new mail as it arrives, keeping both systems in parallel.
Step 6: Cut Over DNS and Validate
On your cutover day — which should be a Friday evening or Saturday morning for most businesses — update the MX records to point to Microsoft 365. Because you lowered the TTL in Step 3, the change takes effect within 5 to 15 minutes for most email servers.
After switching MX records, perform a final sync to capture any mail that arrived at the old server between your last sync and the DNS change. Then validate every mailbox. The validation process is straightforward but tedious: for each mailbox, verify the email count matches between old and new, send a test message to and from the address, check that calendar appointments are present, and confirm that contacts transferred. This takes about 5 minutes per mailbox, so for a 20-person company, budget about two hours for validation alone.
One detail that catches people off guard: mobile devices. Phones and tablets that were connected to your old email server will not automatically switch to Microsoft 365. Each device needs to be reconfigured, either by removing and re-adding the email account or by using Microsoft Intune for managed deployments. If your team uses Outlook on their phones, the app handles the transition more smoothly. If they use the built-in Mail app on iOS or Android, expect to walk them through a manual reconfiguration.
Step 7: Post-Migration Verification and Cleanup
This is the most important step, and it is the one that most people skip. After migration, you need to verify that every mailbox received all its mail, that every alias and forwarding rule works, that calendar items transferred correctly, and that mobile devices reconnected to the new server.
Do not decommission your old email system until you have verified everything. Keep it running for at least 7 days as a safety net. If someone discovers missing email during that window, you can retrieve it from the old server.
During the first week after migration, monitor your DMARC reports. These reports tell you whether any legitimate email from your domain is failing authentication checks. If you see failures, check the SPF and DKIM configuration before tightening the DMARC policy. Common sources of legitimate failures include CRM systems, marketing platforms, and ticketing systems that send email on behalf of your domain but were not included in your SPF record.
The Validation Script That Catches What You Would Miss
I built a Python script that validates your Microsoft 365 migration by checking the DNS records that most people get wrong. It verifies your MX, SPF, DKIM, and DMARC configuration and flags any issues.
#!/usr/bin/env python3
"""
m365_migration_validator.py -- Validates DNS records for M365 migration.
Python 3.10+, stdlib only.
Usage: python m365_migration_validator.py yourdomain.com
"""
from dataclasses import dataclass, asdict
@dataclass
class DnsCheck:
record_type: str
status: str
value: str
recommendation: str
def check_mx(domain: str) -> DnsCheck:
"""Verify MX record points to Microsoft 365."""
try:
result = subprocess.run(
["nslookup", "-type=MX", domain],
capture_output=True, text=True, timeout=10
)
output = result.stdout.lower()
if "mail.protection.outlook.com" in output:
return DnsCheck("MX", "PASS", "Points to Microsoft 365", "MX record is correct.")
elif "mx" in output:
return DnsCheck("MX", "WARNING", output.strip()[:100], "MX does not point to M365. Update to *.mail.protection.outlook.com.")
return DnsCheck("MX", "FAIL", "No MX record found", "Add MX record for Microsoft 365.")
except Exception as e:
return DnsCheck("MX", "ERROR", str(e), "Could not check MX record.")
def check_spf(domain: str) -> DnsCheck:
"""Verify SPF record includes Microsoft 365."""
try:
result = subprocess.run(
["nslookup", "-type=TXT", domain],
capture_output=True, text=True, timeout=10
)
output = result.stdout
spf_records = [line for line in output.split("\n") if "v=spf1" in line.lower()]
if len(spf_records) > 1:
return DnsCheck("SPF", "CRITICAL",
f"{len(spf_records)} SPF records found",
"MULTIPLE SPF RECORDS. Merge into one. This breaks email auth.")
if len(spf_records) == 1:
record = spf_records[0]
if "spf.protection.outlook.com" in record:
return DnsCheck("SPF", "PASS", record.strip()[:100], "SPF includes Microsoft 365.")
return DnsCheck("SPF", "WARNING", record.strip()[:100],
"SPF exists but missing M365. Add include:spf.protection.outlook.com")
return DnsCheck("SPF", "FAIL", "No SPF record", "Add SPF TXT record for Microsoft 365.")
except Exception as e:
return DnsCheck("SPF", "ERROR", str(e), "Could not check SPF.")
def check_dmarc(domain: str) -> DnsCheck:
"""Verify DMARC record exists."""
try:
dmarc_domain = f"_dmarc.{domain}"
result = subprocess.run(
["nslookup", "-type=TXT", dmarc_domain],
capture_output=True, text=True, timeout=10
)
if "v=dmarc1" in result.stdout.lower():
return DnsCheck("DMARC", "PASS", "DMARC record found", "DMARC is configured.")
return DnsCheck("DMARC", "WARNING", "No DMARC record",
"Add DMARC TXT record at _dmarc.yourdomain.com")
except Exception as e:
return DnsCheck("DMARC", "ERROR", str(e), "Could not check DMARC.")
def main():
parser = argparse.ArgumentParser(description="M365 Migration DNS Validator")
parser.add_argument("domain", help="Your email domain (e.g., yourbusiness.com)")
parser.add_argument("--json", action="store_true", help="Output as JSON")
args = parser.parse_args()
checks = [check_mx(args.domain), check_spf(args.domain), check_dmarc(args.domain)]
if args.json:
print(json.dumps([asdict(c) for c in checks], indent=2))
return
print(f"\n M365 MIGRATION VALIDATOR -- {args.domain}")
print(" " + "=" * 50)
for c in checks:
icon = {"PASS": "[OK]", "WARNING": "[!!]", "CRITICAL": "[XX]", "FAIL": "[XX]", "ERROR": "[??]"}[c.status]
print(f"\n {icon} {c.record_type}: {c.status}")
print(f" {c.recommendation}")
print("\n " + "=" * 50)
fails = sum(1 for c in checks if c.status in ("CRITICAL", "FAIL"))
if fails:
print(f" {fails} issue(s) found. Fix before proceeding with migration.\n")
else:
print(" All checks passed. Safe to proceed with migration.\n")
if __name__ == "__main__":
main()
The script checks three things that break most migrations. The check_mx function verifies your MX record points to Microsoft 365 instead of your old provider. The check_spf function looks for the fatal error of having multiple SPF records, which is the single most common DNS mistake during M365 migration. The check_dmarc function confirms you have a DMARC record, which is increasingly required by major email providers in 2026.
Run it with python m365_migration_validator.py yourdomain.com before and after your migration. If everything shows PASS, your DNS is correct and email will flow properly.
For a pre-migration checklist that walks through every step, here is the MJS version:
// m365_pre_migration_checklist.mjs -- Node.js 18+, no dependencies
const steps = [
{
phase: "PLANNING",
text: "Inventoried all email addresses, aliases, and distribution lists?",
critical: true,
},
{
phase: "PLANNING",
text: "Documented current DNS provider and registrar access?",
critical: true,
},
{
phase: "LICENSING",
text: "Purchased Microsoft 365 licenses for all users?",
critical: true,
},
{
phase: "LICENSING",
text: "Created M365 tenant and added custom domain?",
critical: true,
},
{
phase: "DNS",
text: "Lowered DNS TTL to 300 seconds (24+ hours ago)?",
critical: true,
},
{
phase: "AUTH",
text: "Prepared SPF record with spf.protection.outlook.com?",
critical: true,
},
{
phase: "AUTH",
text: "Published DKIM CNAME records for custom domain?",
critical: false,
},
{
phase: "AUTH",
text: "Created DMARC record with p=none policy?",
critical: false,
},
{
phase: "MIGRATION",
text: "Tested pilot batch of 3-5 mailboxes?",
critical: true,
},
{
phase: "MIGRATION",
text: "Verified pilot mailboxes received all historical email?",
critical: true,
},
{
phase: "CUTOVER",
text: "Scheduled cutover for low-traffic window?",
critical: false,
},
{
phase: "CUTOVER",
text: "Updated MX records to Microsoft 365?",
critical: true,
},
{
phase: "CUTOVER",
text: "Performed final sync from old server?",
critical: true,
},
{
phase: "VERIFY",
text: "Verified all mailboxes have correct email count?",
critical: true,
},
{
phase: "VERIFY",
text: "Tested send/receive for every user?",
critical: true,
},
{
phase: "VERIFY",
text: "Confirmed mobile devices reconnected?",
critical: false,
},
{
phase: "CLEANUP",
text: "Kept old email server running for 7-day safety window?",
critical: true,
},
];
async function runChecklist() {
const rl = createInterface({ input: stdin, output: stdout });
let passed = 0;
let criticalFails = 0;
console.log("\n M365 PRE-MIGRATION CHECKLIST\n");
for (const s of steps) {
const a = await rl.question(` [${s.phase}] ${s.text} [y/n]: `);
const ok = a.trim().toLowerCase().startsWith("y");
if (ok) passed++;
else if (s.critical) criticalFails++;
}
rl.close();
console.log(`\n Completed: ${passed}/${steps.length}`);
if (criticalFails > 0) {
console.log(` BLOCKED: ${criticalFails} critical steps incomplete.`);
console.log(
" Do NOT proceed with migration until all critical steps pass.",
);
} else {
console.log(" All critical steps complete. Safe to proceed.");
}
}
runChecklist();
The Four DNS Records That Make or Break Your Migration
Let me be specific about the DNS records you need, because this is where the technical complexity lives and where mistakes are most costly. For related strategies, check out Building a Zero-Touch Deployment Pipeline for Windows Workstations.
MX Record: This tells the internet where to deliver email for your domain. Before migration, it points to your old provider. After migration, it must point to yourdomain-com.mail.protection.outlook.com (with your actual domain name, hyphens replacing dots). If this record is wrong, email goes nowhere.
SPF Record: One TXT record, not two, not three. The value should be v=spf1 include:spf.protection.outlook.com -all for a domain that only sends email through Microsoft 365. If you also use a CRM or marketing platform that sends email on your behalf, include those servers in the same record: v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all. The most common mistake we see in DeLand and Daytona Beach businesses is leaving the old provider in the SPF record alongside Microsoft 365, which is acceptable, or having two separate SPF TXT records, which is fatal.
DKIM CNAME Records: You need two CNAME records: selector1._domainkey.yourdomain.com and selector2._domainkey.yourdomain.com, both pointing to Microsoft 365 DKIM keys. These are generated automatically when you enable DKIM in the Microsoft 365 Defender portal. Without DKIM, your emails may pass SPF but fail DMARC alignment at strict receivers like Gmail, which could route your messages to spam.
DMARC TXT Record: At _dmarc.yourdomain.com, set v=DMARC1; p=none; rua=mailto:[email protected]. Start with p=none so you receive reports without blocking email. After 2 to 4 weeks of clean reports, upgrade to p=quarantine and then p=reject. This progression protects your domain from spoofing while giving you time to identify and fix any legitimate mail that fails authentication.
What the Custom-Built Version Looks Like
The scripts and the 7-step process give you everything you need for a straightforward migration. But email environments are rarely straightforward. Shared mailboxes, distribution groups with external members, mail flow rules that route email to ticketing systems, journal rules for compliance, and legacy applications that send email via SMTP relay all add complexity that the basic migration process does not cover.
When we handle M365 migration for a business, we start with a complete email environment audit. We document every mailbox, alias, group, rule, and integration point. We test the migration with a pilot batch and verify not just email delivery but calendar syncing, contact transfer, and mobile device connectivity. We handle the DNS changes ourselves, including the authentication records that most people miss. And we monitor the first 72 hours post-migration to catch any issues before they become problems.
For businesses in DeLand, Daytona Beach, and across Volusia County, we have done this migration dozens of times. The process takes one weekend of active work for most businesses under 30 users, and your team shows up Monday morning to email that works exactly like before, except it is faster, more reliable, and backed by Microsoft’s enterprise infrastructure.
One thing that surprises many business owners is how much better Microsoft 365 email is compared to what they were using before. Mailboxes start at 50 GB instead of the 1 to 5 GB that most budget email providers offer. Search actually works across years of email history. Spam filtering is dramatically better because Microsoft processes billions of messages daily and has the dataset to train their filters properly. And features like Focused Inbox, shared calendars, and Teams integration are included at no additional cost.
For medical practices and law firms in Volusia County that need email archiving for compliance, Microsoft 365 Business Premium includes litigation hold, eDiscovery, and email archiving that would cost $10 to $20 per user per month as a standalone service. When you factor in these capabilities, the migration is not just a lateral move. It is a significant upgrade that happens to also cost less than what most businesses pay for their current email.
For a full cost analysis of cloud migration including email, check our cloud migration cost guide.
The Five Most Common Migration Mistakes (And How to Avoid Them)
After handling dozens of M365 migrations, I have seen every way this can go wrong. Here are the five mistakes that cause the most pain.
Mistake 1: Changing MX records before syncing mailbox data. If you point email to Microsoft 365 before migrating your historical email, new messages arrive in M365 while old messages sit on the old server. Your users see an empty inbox and panic. Always sync first, cutover second.
Mistake 2: Creating multiple SPF records. This is the number one DNS error. When you add a new SPF record for Microsoft 365 without removing or merging the old one, you end up with two SPF TXT records. The DNS specification says a domain can only have one SPF record. When there are two, email receivers reject both. Your outgoing email stops being authenticated and starts landing in spam, or worse, gets rejected entirely.
Mistake 3: Forgetting about shared mailboxes and distribution groups. Individual mailboxes migrate cleanly, but shared mailboxes, room resources, and distribution lists need separate attention. If your office has a shared mailbox like [email protected] or [email protected], it needs to be recreated in Microsoft 365 and migrated separately.
Mistake 4: Not testing before going live. Pilot testing with 3 to 5 users catches issues that only appear in practice: Outlook profile configurations, mobile device compatibility, and third-party application integrations. Skipping the pilot means discovering these issues with your entire company on Monday morning.
Mistake 5: Decommissioning the old server too early. Keeping the old email system running for 7 days costs almost nothing and provides an essential safety net. Shutting it down immediately after cutover means you cannot recover if something was missed. We have seen businesses delete their old email server on cutover day, only to discover a week later that a critical shared mailbox was not included in the migration.
Ready to migrate your email to Microsoft 365? Schedule a free assessment and we will audit your current email setup, plan the migration, and handle the entire process.
Based in DeLand? Visit our DeLand IT consulting page to learn about our local services.
Frequently Asked Questions About M365 Email Migration
How long does a Microsoft 365 email migration take?
For a small business with 10 to 25 mailboxes, the data transfer itself takes 4 to 8 hours depending on mailbox sizes. However, the total process including planning, DNS preparation, pilot testing, and post-migration verification takes 1 to 2 weeks. The actual cutover — the moment when email switches from your old system to Microsoft 365 — takes less than an hour. We schedule cutover for Friday evenings so the DNS changes propagate over the weekend and everything is stable by Monday morning.
Will I lose emails during migration to Microsoft 365?
Not if the migration is done correctly. The Microsoft migration tools sync your mailbox data incrementally, meaning they copy everything first and then keep syncing new mail until cutover. After cutover, we perform a final sync and then verify every mailbox. The risk of data loss comes from DIY migrations where someone deletes the old mailbox before verification, or where DNS records are misconfigured causing mail to be delivered to the wrong server during the transition window. Following the 7-step process in this guide eliminates those risks.
How much does M365 migration cost?
Microsoft 365 Business Basic is $6 per user per month. Business Standard with desktop Office apps is $12.50 per user per month. For a 10-person business, that is $60 to $125 per month for email, file storage, and collaboration tools. Professional migration services typically cost $500 to $3,000 depending on mailbox count and complexity. If you currently pay $5 to $10 per mailbox to your old email provider, the cost difference is minimal and you gain a significant upgrade in features, reliability, and security.
Do I need to change my email address?
No. You keep your existing email addresses exactly as they are. Migration moves the mailbox — the data and the delivery destination — from your old provider to Microsoft 365. Your domain stays the same, your email addresses stay the same, and anyone sending you email sees no change. The only thing that changes is which servers handle your email behind the scenes.
What happens to my old emails?
Every email in your old mailbox migrates to Microsoft 365. The migration tool copies emails, folders, read/unread status, and folder organization. Nothing is deleted from your old system during migration — we leave the old mailboxes intact for at least 7 days after cutover as a safety net. Only after you have verified that everything transferred correctly do we decommission the old email system.
Can I migrate from Gmail to Microsoft 365?
Yes. Microsoft provides built-in migration tools specifically for Google Workspace to Microsoft 365 migrations. These tools transfer email, contacts, and calendar events. The process is similar to the 7-step approach described in this guide, with additional steps for Google-specific items like Google Drive files (which migrate to OneDrive) and Google Sites (which need manual recreation). We handle Google to M365 migrations regularly for businesses in Volusia County that are consolidating onto the Microsoft platform.
What Microsoft 365 Gives You That Your Current Email Does Not
Let me be specific about what you gain, because the migration is not just about moving data — it is about upgrading your email infrastructure permanently.
Storage: Most budget email providers give you 1 to 5 GB per mailbox. Microsoft 365 gives you 50 GB. That is enough to store years of email without ever archiving or deleting messages. You stop getting “mailbox full” errors permanently.
Security: Microsoft spends more than $1 billion per year on cybersecurity. Their spam and phishing filters are trained on billions of messages daily. Your hosted email provider at $5 per month is not making that kind of investment. The difference in phishing protection alone justifies the migration.
Compliance: For businesses that handle sensitive data — healthcare practices, law firms, financial services — Microsoft 365 Business Premium includes litigation hold, eDiscovery, and email archiving. These features would cost $10 to $20 per user per month as standalone add-ons from other providers.
Reliability: Microsoft guarantees 99.9 percent uptime for Exchange Online. That is less than nine hours of total downtime per year. Most budget email providers do not offer an SLA at all, let alone one that meaningful.
Mobility: Outlook for iOS and Android provides native push email, calendar, and contacts with enterprise security features. Your team can access email securely from any device, anywhere, with the same policies that protect their desktop.
The Bottom Line
Email migration to Microsoft 365 is not technically difficult, but it is unforgiving of mistakes. A misconfigured SPF record means your email goes to spam. A skipped validation step means missing data you do not discover until someone complains. A premature DNS change means mail going to a black hole.
The good news is that every one of these mistakes is avoidable. The 7-step process, the validation script, and the pre-migration checklist in this guide are the same tools we use internally for every migration. They exist because we learned the hard way which steps matter and which shortcuts lead to 2 AM phone calls from panicked business owners who cannot send email.
If you are currently paying for hosted email through GoDaddy, Rackspace, Network Solutions, or your web hosting provider, the migration to Microsoft 365 is almost certainly worth doing. The cost is comparable or lower, the features are dramatically better, the reliability is enterprise-grade, and the security posture is years ahead of most budget email providers. The only question is whether you want to handle the migration yourself using this guide or have someone do it for you over a weekend.
Follow the 7-step process. Run the validation script. Use the checklist. And if you want someone to handle the whole thing so you do not have to worry about DNS records and DKIM selectors, we are right here in DeLand and across Volusia County, and we have done this migration more times than we can count.