No mystery, no jargon. Here's the real, step-by-step process we run for a typical small team — the same 48-hour, zero-downtime move we'd run for your business or church.
Check my domain →A 12-person office running email through their website hosting. On the surface it "works" — but under the hood: no SPF alignment, no DKIM keys, no DMARC policy, MX pointed at a shared host, and a handful of client replies quietly going to spam every week. Nobody realizes how much is slipping through until we look.
We run a real DNS + deliverability audit and deliver a one-page report: what's broken, what it's costing them, and what fixed looks like. This is where "our email is fine" turns into "oh."
With approval, we provision Google Workspace or Microsoft 365, migrate every mailbox, calendar, and contact, and stage the cutover — all while old email keeps flowing. Zero downtime.
We publish correct SPF, DKIM, and DMARC, cut over MX, and verify authentication end-to-end. By the end of day two, mail is landing in inboxes and the domain can't be spoofed.
From that point on, it's a simple monthly retainer: we watch the deliverability, keep the DNS clean, and pick up the phone when something's off. You never have to think about email plumbing again.
Note: this is an illustrative walkthrough of our standard process. We'll publish named client results here as clients come on board.
It starts with a free audit of your domain. You'll see exactly where you stand before committing to anything.
Check my domain →This is the part church staff worry about most, and it's the part that actually causes the least disruption. Once every mailbox, calendar, and contact list has been fully copied over — not just started, but verified complete and matching the original — we schedule the DNS cutover for a low-traffic window, usually late evening or early Sunday morning before anything picks up.
We update the MX records to point at Google Workspace or Microsoft 365, and email starts arriving at the new destination within minutes. Because we migrated everything in advance, there's no gap where mail bounces or goes missing — old messages are already sitting in the new inboxes waiting, and new messages simply start landing there instead. Staff open their laptops Monday morning to find their same inbox, same folders, same calendar invites, just running on infrastructure that actually authenticates properly.
We also set correct SPF, DKIM, and DMARC records as part of this step — the same three things that were missing or broken in the audit. That's what stops the "replies quietly going to spam" problem for good, not just for the migrated accounts but for every email your church domain sends going forward.
Church and ministry email setups tend to share a specific pattern, because most were configured years ago by a volunteer or a web hosting company bundling email in with the church website — not by someone thinking about deliverability. We see the same handful of issues over and over.
The most common: a shared church-wide inbox (like info@ or office@) that three or four staff all log into with the same password, with no record of who sent what. Close behind that is calendar chaos — a facilities calendar, a pastoral calendar, and a events calendar living in three different systems that don't talk to each other, so double-bookings happen at the worst times. And almost universally, we find that giving letters, donor receipts, and newsletter sends are landing in spam because the sending domain has no SPF/DKIM alignment — which means the church may be losing donations simply because the "thank you for your gift" email never arrived.
None of these are unusual or embarrassing — they're what happens when email was set up once, years ago, and nobody's touched it since. Fixing them is routine work for us; it's just invisible to anyone who isn't looking for it.
A migration doesn't end at cutover — the first two weeks are when we make sure it actually stuck. We monitor mail flow daily to confirm nothing is bouncing, check that DMARC reports show your domain passing authentication (not just configured, but actually passing), and follow up directly with any staff member who flags something that looks off.
For most churches, this period is quiet by design. Because we migrate mailboxes completely before the cutover rather than syncing them live, there's no "some of my old emails are missing" scramble that happens with cheaper DIY migration tools. Where we do spend time is training: a short walkthrough for staff and volunteers on the new Google Workspace or Microsoft 365 tools, especially shared calendars and shared drives, since that's usually new even to people who've used Gmail personally for years.
By the end of two weeks, deliverability is measurably better — you can see it directly in the DMARC reports, which is also the same data point we'll come back to during any future audit. Most churches tell us the difference isn't just technical; it's that the office finally isn't fielding "did you get my email?" calls anymore.
Will our staff lose access to old emails during the move? No — every mailbox is fully copied to the new platform before we touch DNS, so nothing is deleted or in-transit when the cutover happens. Your team keeps working normally the whole time.
Do we need technical staff on our end? No. We handle DNS, provisioning, and the technical migration end-to-end. We just need someone who can approve DNS changes with your domain registrar (or give us access to do it), which usually takes fifteen minutes.
What happens to our donor and giving records tied to email? Nothing changes about your giving platform integration — we're moving where email lives, not touching your CRM or donor database. If your giving receipts were landing in spam before, that's specifically what the SPF/DKIM/DMARC fix resolves.
Is there real downtime? No — this is a zero-downtime migration. The 48-hour window covers provisioning and full mailbox migration; the actual DNS cutover itself takes effect within minutes and happens on a schedule you approve.