Source Reddit post: https://www.reddit.com/r/msp/comments/1ur981s/what_are_we_using_for_email_migrations_under_100/
Classification: opportunity / idea_filter
Build a lightweight quoting and cutover-control desk for small MSPs doing under 100 mailboxes Google Workspace to Microsoft 365 migrations, especially 10-100 mailbox projects, so they can choose native Microsoft vs paid tools, package the scope cleanly, and protect margin on one-time projects.
Small MSP owners, project techs, and service managers who occasionally move SMB clients from Google Workspace to Microsoft 365, usually below 100 seats, and quote the work per mailbox rather than as a large professional-services project. The strongest first wedge is the 20-80 mailbox project where there is email plus contacts and calendars, but no complex Drive/SharePoint migration.
The seed buyer language is unusually explicit: the OP says AvePoint Fly now requires an "annual subscription," which makes "migration costs insane" for a one-time project; their per-mailbox model means "the math is not mathing" unless they "charge double." They also valued "delta syncs" and "automatic DNS setup," and the concrete project is "about 60 mailboxes + contacts and calendars, not Drive." That is exactly a pricing-and-runbook choke point, not a generic M365 licensing problem.
The source r/msp post is only treated as pain discovery, but it is high-quality pain discovery because it combines buyer, project size, current substitute, pricing trigger, and feature requirements in one post. The OP has used AvePoint Fly, previously SkyKick, is cautious after SkyKick's ConnectWise acquisition, sees a love-hate relationship around BitTitan, and is asking whether Microsoft's native migration is worth evaluating.
A concrete Reddit comment is available: https://www.reddit.com/r/msp/comments/1ur981s/what_are_we_using_for_email_migrations_under_100/owehoil/ says the built-in M365 migration tools "work better than any 3rd party" and asks why pay for a third-party tool. Another comment recommends CodeTwo. That split is the product opening: MSPs need a fast way to decide when native is enough, when a paid tool saves labor/risk, and how to quote either path.
Microsoft Learn says the Exchange admin center batch migration can migrate email, contacts, and calendars from Google Workspace to Microsoft 365, keep both environments active, move users in groups, and schedule start/end of migration batches. Microsoft also documents prerequisites around Google permissions, domain/subdomain setup, DNS records, proxy addresses, routing domains, Exchange licenses, and completing a batch when status is Synced.
The important nuance: native Microsoft is a viable low-tool-cost option for some small projects, but it still creates preflight and cutover work. Microsoft also documents limitations: room bookings, shared calendars, event colors, Gmail contact tags/URLs/custom tags, and more than three email addresses per contact may not migrate. It warns MRM/archival policies can make items appear missing. That means an MSP cannot just say "native is free" without a checklist, client expectations packet, exception tracker, and go/no-go logic.
Paid vendors market around staged/pre-seeded migrations, delta sync, cutover reliability, mapping, reports, and reduced user downtime. BitTitan's own Google-to-M365 guidance tells customers to inventory users and data, pre-stage mailboxes, change MX/autodiscover DNS at cutover, and run a final pass after cutover. BitTitan pricing is visible in search results as Mailbox at about $14/user and User Migration Bundle at about $17.50/user, with a help article positioning mailbox licenses for mailboxes under 50 GB and bundles for mail/doc/archive workloads.
ConnectWise/SkyKick's Cloud Migration page markets end-to-end Microsoft 365 migration automation for partners, with email, calendar, contacts, signatures, rules, staged syncs, throttling controls, and final delta near cutover. Cloudiway markets Google-to-Microsoft 365 migration with Gmail, Google Drive, Calendar, Contacts, Chat, Groups, Vault, Sites, zero downtime, and delta sync. CodeTwo advertises Google/Zimbra/IMAP-to-M365 migration, contacts/calendars, cutover/staged/hybrid migration, automatic delta migrations, automatic mailbox matching, scheduled migration, reports, and user licensing. Movebot markets discovery scans and advanced delta migrations, though its page leans more file/data-oriented.
This validates that the missing capabilities are commercially recognized. The opportunity is not to replace MigrationWiz/SkyKick/AvePoint. It is to sit one layer above them as the small-project decision, quote, and cutover desk.
The product should be a service-first micro-tool for MSPs who are about to quote a Google Workspace to M365 move and need an answer in 30 minutes:
1. Quote calculator: mailbox count, mailbox size bands, contacts/calendars, Drive excluded/included, after-hours cutover, DNS ownership, identity cleanup, user comms, post-migration support hours, paid tool license cost, native-tool labor estimate, margin target, and risk buffer.
2. Tool-choice matrix: native Microsoft vs BitTitan vs SkyKick/ConnectWise vs AvePoint vs CodeTwo vs Cloudiway/Movebot, with use-case logic such as "60 mailboxes, email/contacts/calendars, no Drive, low label complexity" vs "large labels/files/permissions/coexistence/Drive."
3. Preflight checklist: Google admin access, Microsoft tenant/domain readiness, licenses, routing domain, user mapping, aliases, forwarding rules, calendar/contact caveats, mailbox sizes, Gmail labels, DNS host access, TTL changes, SPF/DKIM/DMARC notes, and client approvals.
4. Cutover runbook: T-minus schedule, pre-stage/delta-sync schedule, MX/autodiscover/SPF changes, validation steps, final sync, user login instructions, Outlook/mobile setup, rollback notes, and next-business-day support queue.
5. Client-facing scope/price packet: explains what is included, what is excluded, tool choice, known native limitations, data types covered, after-hours expectations, and why a low-seat migration can still require structured work.
6. Exception tracker: failed users, missing contacts/calendar issues, large messages, label/folder mapping oddities, DNS delays, mobile setup tickets, and post-migration user complaints.
The wedge should be a paid fixed-price "migration quote and cutover packet" rather than broad SaaS at first. Brian could sell an audit/packet for a small fee or use it as a done-with-you service: the MSP shares mailbox counts and constraints; Brian returns a quote model, tool recommendation, runbook, and client packet.
Weekend-buildable MVP:
Do not start with API automation into Microsoft or Google. The urgent value is project math plus a clean operating packet, not moving data.
Start where the pain already appears:
A good outbound opener: "When a client asks for a 40-80 seat Google-to-M365 move, how do you decide whether native migration is enough, and where does your quote calculator account for final delta, DNS, contacts/calendars, and next-day support?"
Substitutes are strong:
The gap is that none of those substitutes are primarily a small-MSP margin-preservation layer. Vendor docs sell their own tool. Native docs explain one path. The MSP still has to quote the project, explain why a 60-mailbox job costs what it costs, pick the right tool, schedule deltas, handle DNS, and track exceptions.
The biggest uncertainty is whether MSPs will pay for a decision/runbook desk when they can ask peers on r/msp and use vendor docs. The strongest source is a single fresh Reddit post; more interviews are needed. Pricing evidence for AvePoint's annual model is partly search-result/vendor-marketplace based, not a fully extracted current contract page. Also, the tool matrix could become stale quickly. The report may underweight the possibility that CodeTwo, Cloudiway, or ConnectWise already package enough quoting/project controls for partners. Validation should ask MSPs to show their actual quote spreadsheet, not just react to the idea.
REDDIT_RESPONSE_DRAFT_START
Yeah, this is exactly where the pricing model gets weird. For a 60-ish mailbox Google to M365 move with contacts/calendars and no Drive, I’d quote it from two paths side by side: native Microsoft if the mailbox sizes/labels/calendar expectations are boring enough, then a paid tool path only if you need cleaner delta passes, better reporting, or less cutover risk. That keeps the client from seeing “we picked an expensive tool, so your price doubled” without context.
The thing I’d standardize is a small calculator/runbook: mailbox count and sizes, contacts/calendars, label weirdness, DNS access, pre-stage/final delta timing, after-hours cutover, and a post-migration exception bucket. Happy to sketch the calculator/checklist structure if useful, because the real pain is making the math and cutover risk visible before you send the quote.
REDDIT_RESPONSE_DRAFT_END
A focused MSP migration quoting and cutover-control desk has real margin pain and a buildable workflow wedge, but distribution and repeat usage are narrower than Brian’s best SMB automation opportunities.