New email setup
- Email that does not exist yet on your domain
- No old mail to carry across
- Business Email Setup, $250 one-time, with the scope listed below
- Microsoft or Google subscriptions and domain fees paid directly by you
Business email migration
Move your email without losing any
Moving email providers is not risky because it is technically hard. It is risky because your business does not stop while it happens, and mail that bounces during a cutover is a customer you never hear from. TechTruePoint plans and runs email moves for businesses across Dallas-Fort Worth and the rest of the US, fully remote. Ask for a quote and say what you are moving from.
An email migration is moving existing mailboxes from one provider to another with the history intact and no gap in delivery. That is a different job from setting up new email: there is data to carry across, a live service that must not stop, and a moment where mail delivery changes hands.
Done properly it is dull. The mail is copied while the old system is still running, the switch happens at a time you chose, and a second pass sweeps up anything that arrived in between. Done as a single dramatic evening of flipping records, it is how businesses lose quotes they never knew arrived.
New email setup or a migration?
They are two different jobs. New email on your domain has one published price. Moving existing mail is quoted on its own, because it depends on what you have now.
Email migration (this page)
- Mailboxes that already exist somewhere else
- Old mail, contacts and calendars carried across
- A planned switchover and a way back if needed
- Quoted individually once we know what you have
New business email
Business Email Setup $250 one-time
Professional email using your business domain, configured with Microsoft 365 or Google Workspace.
- One domain and up to three users.
- New email account setup and domain verification.
- Email routing and SPF, DKIM and initial DMARC records, set up for your provider and domain.
- Two-step sign-in (multifactor authentication) turned on for every user.
- Connection on one supported device per user.
- Sending and receiving tests, and a short handoff.
- Seven days to report and correct any issue caused by our setup.
Good to know
- Microsoft or Google subscriptions and domain fees are separate. You pay them directly to Microsoft, Google or your domain company.
- Moving old email across, account recovery, repairs to an existing system and extra devices are quoted separately.
- You own your accounts and your domain.
- We confirm the job fits this package before you pay and before anything is changed.
Why the order of operations is the whole job
The technical steps are not exotic. The sequence is what separates a boring migration from a bad one.
Copy first, while the old system still works
Mail gets copied to the new provider before anything about delivery changes. The old mailboxes carry on receiving throughout. Nothing is at stake yet, because if the copy stalls or the tooling misbehaves, your business has not noticed: mail is still arriving where it always did.
This is the opposite of how it goes wrong. The wrong way is to point the MX records at the new provider first and then start moving data, which means every problem from that moment on is happening to live mail.
Lower the TTL before you need to
Your DNS records have a TTL: how long other servers may cache them before asking again. Leave it high and mail servers all over the world will keep delivering to your old provider well after you switched, because they are working from a remembered answer.
So the TTL comes down ahead of the cutover, giving the old value time to expire everywhere. Then the change propagates quickly instead of dribbling out over days with mail landing in two places. Afterwards it goes back up. It costs nothing and it is skipped constantly.
Switch delivery, then sweep up
The MX records change and new mail starts arriving at the new provider. Then a second copy pass catches everything that landed in the old mailboxes between the first copy and the switch. That delta pass is what makes the difference between "we moved your email" and "we moved most of your email".
Keep the old system until you are sure
The old mailboxes stay, with their data, until the new setup has been running long enough to trust. That is your rollback. A migration without one is a leap of faith with your business correspondence.
The part everyone forgets: your mail has to be believed
Moving delivery is only half of it. The other half is whether the rest of the internet accepts mail from your new provider as genuinely yours.
Your SPF record lists who may send as your domain. Change providers and that record has to change too: otherwise you are sending from somewhere your own domain does not vouch for, and receiving servers act accordingly. DKIM has to be re-established at the new provider so your mail is signed. DMARC has to be consistent with both, or you can end up instructing the world to reject your own mail.
This is the classic post-migration complaint. The move went fine, everyone is on the new system, and a week later half the invoices are landing in spam. Nobody connects the two events, because the mail is technically arriving, just not where anyone looks. It is authentication, every time. There is more at business email going to spam, and the records themselves live in DNS: see Cloudflare and DNS management.
Moving to Microsoft 365
When the destination is Microsoft 365, the mail lands in Exchange Online. The sequence above does not change. What changes is what can come across, and that depends on where the mail lives now.
From IMAP hosted email
The mail that came with your web hosting or domain registrar, usually read through Outlook or a phone app. Mailboxes and folders can be copied into Exchange Online over IMAP, but IMAP only carries mail. Contacts and calendars have to be exported and brought across separately, and that is worth knowing before anyone promises a like for like move.
From Google Workspace
Mail, calendars and contacts can all be moved into Microsoft 365, and the Google side stays live until you are ready to switch delivery. Shared drives and Google Docs are a separate job from the mailboxes and need their own plan for where they land in SharePoint and OneDrive.
From older hosted Exchange
A hosted Exchange provider, or an Exchange server that has been in a cupboard for too long. Mail, calendars and contacts come across, and permissions such as shared calendars and delegated mailboxes are checked on the other side rather than assumed.
From another Microsoft 365 tenant
After an acquisition, a split, or a business leaving a provider's tenant for one of its own. This is its own kind of migration, because a domain can only belong to one tenant at a time, so the cutover includes moving the domain itself. If the real problem is that you cannot get into the tenant you are leaving, that is tenant takeover first.
The DNS cutover into Microsoft 365
On the day, MX moves to Exchange Online and the Autodiscover record is updated so Outlook finds the new mailboxes. SPF is changed to include Microsoft 365 as a sender, DKIM signing is switched on for your domain in Microsoft 365, and DMARC is checked against both. Every one of those records is written down beforehand, which is what makes the rollback real.
People and devices
Outlook profiles, phones and tablets all need pointing at the new mailbox, and somebody always has an old app that keeps the previous account. We plan that part as carefully as the data, because it is the part your team actually experiences. If laptops are being enrolled at the same time, that is Intune and Autopilot, and it is usually easier done in the same project.
None of this means no disruption at all. Most people notice a changed sign in and a phone that needs reconnecting. The aim is that nobody notices missing mail. Once it has settled, Microsoft 365 administration keeps it running.
Moving from Gmail to Google Workspace
Plenty of businesses start on a personal Gmail address and outgrow it. Moving to Google Workspace on your own domain keeps the history and puts the mail in an account the business owns, not one person.
What comes across
Mail can be copied from the old Gmail account into the new Workspace account with Google's own migration tools. Contacts and calendars are exported and brought across as their own steps, so each one is checked on its own.
What changes for your customers
The address changes, which is the point. The old Gmail can forward to the new address and send an automatic reply for a while, so no message falls through the gap while customers update their contacts.
Before any of it
Google has to verify your domain first, and that is where most of these moves get stuck. If it keeps failing, read Google Workspace setup on why. The old account is never deleted as part of the move; it stays until you are sure nothing still arrives there.
How we approach it
-
Find out what is actually there
How many mailboxes, how much history, what is a real account and what is an alias pretending to be one, and whether the old provider will hand the data over cleanly. This is discovery, and it changes the plan more often than not.
-
Document every DNS record before anything moves
The current zone written down as it stands, so there is something to compare against and something to restore from. This is the rollback path, created before it is needed rather than during a panic.
-
Lower the TTL ahead of the cutover
Done early so the old cached value has expired everywhere by the time the switch happens. Ignore this step and the move has a long tail with mail arriving in two places.
-
Copy the mail while the old system is still live
Mailboxes, folders, contacts and calendars copied across in the background. Everyone keeps working. Nothing is at risk yet, which is exactly the point.
-
Cut over at a time that suits you
MX records switched when it is quiet for your business, not when it is convenient for us. New mail starts arriving at the new provider.
-
Run the delta pass
A second sweep for everything that arrived after the first copy and before the switch. This is what makes it a complete migration rather than a mostly complete one.
-
Re-establish authentication and test it properly
SPF, DKIM and DMARC corrected for the new provider, then real mail sent to real destinations to see where it lands. Assuming it works is not testing it.
-
Leave the old system standing until you are confident
Nothing is torn down on the day. The old mailboxes stay until the new setup has proved itself in normal use.
What a safe migration includes
- Discovery. Real mailbox count, history volume, aliases and groups, and what the old provider will actually release.
- A documented DNS baseline. Every record as it stands today, written down before a single change.
- TTL planning. Lowered ahead of the cutover so the change takes effect quickly, restored once things settle.
- A pre-cutover copy. Mail, contacts and calendars moved while the old system is still receiving.
- A chosen cutover window. Scheduled around your trading, not ours.
- A delta pass. The sweep for mail that arrived during the changeover. The step that gets skipped.
- Authentication rebuilt. SPF, DKIM and DMARC corrected for the new sender, so your mail is still believed.
- Device reconfiguration. Phones and laptops connected to the new system, including the person who is always on holiday that week.
- A rollback path. The old system intact and the records documented, so reverting is a step rather than an improvisation.
When you should not migrate
We would rather talk you out of this than take the work and hand you a problem.
- When nothing is actually wrong. "We should probably be on something newer" is not a reason. If mail arrives, is backed up, and the team can work, moving it is risk with no return.
- When the real problem is deliverability. If your mail is going to spam, changing provider may not fix it, because the cause is usually your authentication records rather than your host. Fix the records first; you may find you never needed to move.
- When there is no history worth keeping. If you genuinely do not need the old mail, a fresh setup is simpler, faster and cheaper than a migration. Do not pay to move data nobody will open.
- When nobody can get into the current system. Not a blocker, but it changes everything. Data you cannot authenticate to is data you cannot export, and that has to be solved before a date is put in a calendar.
- During your busiest week. The technical work does not care. Your customers do. Cutovers get scheduled around trading, always.
Who this is for
- Businesses moving between Microsoft 365 and Google Workspace, in either direction
- Anyone stuck on mail from a host or provider they have outgrown or cannot get support from
- Businesses that took over a domain and inherited mail nobody understands
- Owners consolidating mail that ended up spread across several providers and personal accounts
- Anyone who has been quoted a migration and wants to know how the cutover will actually be sequenced
When this is not the right fit
- Businesses whose current email works fine. There is no prize for moving, and every move carries risk.
- Anyone whose real complaint is mail landing in spam. That is usually authentication, not provider, and moving may change nothing.
- Businesses with no mail history worth keeping. A clean setup is a smaller, cheaper job.
- Anyone who needs it done tonight with no discovery. Speed is exactly how mail gets lost, and we would be the ones who lost it.
What TechTruePoint can help with
We administer both Microsoft 365 and Google Workspace, so we move businesses in both directions and have no reason to steer you. The plan exists before anything moves, and the rollback exists before it is needed.
- Discovery of what you actually have, before any date is agreed
- Mailbox, contact and calendar migration between providers
- Microsoft 365 tenant, Exchange, Teams, SharePoint and OneDrive administration
- MX and TTL cutover planning, scheduled around your trading
- The delta pass, so mail arriving mid-cutover is not stranded
- SPF, DKIM and DMARC rebuilt for the new provider so deliverability survives the move
- DNS handled directly where the domain is on Cloudflare
- Devices reconnected and people shown what changed
- A documented rollback path that exists before the switch
Common questions
Will we lose email during the move?
Not if the sequence is right. The way it is done: copy the mail across while the old system is still live and receiving, so nothing depends on the copy finishing. Then switch delivery. Then copy again to sweep up anything that arrived during the changeover.
Mail is only ever lost when someone flips the MX records first and hopes. There is no reason to work that way, and every reason not to.
How long does an email migration take?
It depends on how many mailboxes there are, how much history each one holds, and how cooperative the old provider is about letting the data out. The copying happens in the background while everyone keeps working, so the part that affects your day is the cutover itself, which is short.
The honest planning answer: the copying takes as long as it takes and does not disrupt you. The cutover is scheduled for when it suits you, and that is the only bit anyone notices. The full breakdown of where the time goes, and what stretches it, is written up in how long email migration takes.
Do we keep our old emails, contacts and calendars?
That is the point of doing a migration rather than just creating new mailboxes. Mail, folder structure, contacts and calendars come across. Exactly how completely depends on what you are moving from and what it will hand over, which is something we establish before quoting rather than after.
If you did not need the history, you would not need a migration: you would need a fresh setup, which is a smaller job.
What is a TTL and why does it matter for the cutover?
TTL is how long other mail servers are allowed to remember your DNS records before checking again. If it is set high, servers around the world keep sending to your old provider long after you have changed the record, because as far as they know nothing has changed.
So you lower the TTL well ahead of the move. Then when the switch happens, the world picks it up quickly instead of trickling over for days. Once things have settled, it goes back up. Skipping this is why some migrations have a long, messy tail where mail arrives in two places.
Can we go back if something goes wrong?
Yes, if it was planned that way, and that is a condition of doing it rather than a bonus. The old mailboxes stay in place and keep their data until the new system has been running long enough to trust. The DNS records are documented before any change, so reverting is a known step and not an improvisation.
A migration with no rollback path is not a migration, it is a leap.
Do we have to move to Google or Microsoft?
Those are the two we most often move businesses onto, in both directions, because they are where most small businesses end up. But the reason to move should be a real problem you are having, not a logo. We would rather tell you your current setup is fine than migrate you for the sake of it.
Related services and guides
Free email and DNS checker
Check your mail servers, SPF and DMARC in seconds, explained in plain English.
Google Workspace setup
Business email, files and calendars on your own domain.
Cloudflare DNS management
DNS records, nameservers, SSL, caching and protection, configured properly.
Business email going to spam
Authentication, reputation, and the fixes that actually move the needle.
Small business IT consulting
Straight advice on the systems your business runs on.
Get a quote
Tell us what you need and we will map out the simplest path.
Get a Quote
Need to move your mail without a bad week?
Tell us where your email lives now and where it needs to go. We will map the cutover before anything moves.