Your mail stays where it is. That’s the whole of it, and it’s why this switch costs you an afternoon.
A migration was always work on the distance between two mailboxes. Every hour went on closing that distance. Someone built the far end, copied the mail across, proved the copy was complete, redirected the delivery, then swept up whatever landed while the copying ran. Change only the app you read in and there’s one mailbox. It sits in one place. It takes delivery at the same address the whole time, and the list of things that have to be made to match is empty.
- A migration exists because a different server has to end up holding what the old server held. Every line on the plan comes from that one requirement. Each line serves the copy, and making your mail more useful sits outside the plan entirely.
- The expensive parts are the copy, the change to where mail gets delivered, and the gap between them. Microsoft spells out that gap on its own documentation page. Mail arriving at the old system afterward stays there.
- Connect an app to the account you already have and none of that starts. Google or Microsoft still takes delivery, still stores the mail, and still bills you for the mailbox.
- There’s one wait, and it’s a read rather than a transfer. It can finish whenever it finishes, because every message stays in your mailbox while it runs.
- A few things stay behind, like a signature or a filing rule. They stay behind in a real migration too, and Google lists them as unsupported on its own migration page.
What the migration weekend was paying for
Think about who was busy during the last one you sat through. Somebody else spent three weeks on it. Your part was a Monday morning spent looking for your folders. Here’s what those three weeks held, taken from the documentation the person doing it was working from.
The destination had to be built before anything could move. Microsoft states it plainly: “IMAP migration also doesn’t create mailboxes in Microsoft 365 or Office 365. You’ll have to create a mailbox for each user before you migrate their email” (Microsoft Learn, checked September 6, 2026). So every person in the company needed a licensed, named, empty mailbox. Each one sat there waiting before a single message crossed.
The copy needed a way into every source mailbox. That means credentials for all of them, and Microsoft is direct about the fallback: “If you can’t access user mailboxes, you’ll have to reset the passwords” (Microsoft Learn, checked September 6, 2026). If you’ve ever wondered why the week before a migration held a forced password change that nobody explained, that sentence is why.
The copy itself has edges, and they’re lower than people assume. “You can migrate a maximum of 500,000 items from a user’s mailbox (emails are migrated from newest to oldest)”, and “The biggest email you can migrate is 35 MB” (same page, checked September 6, 2026). Read the direction of travel in the first one. When the cap bites, the oldest mail falls off the end. That’s the part of a mailbox people keep for exactly the reason that it is old.
Then somebody had to prove every message arrived, which is harder than it sounds. Microsoft “strongly recommends disabling all MRM and archival policies before attempting any data migration to mailboxes” (same page, checked September 6, 2026). Leave those policies on and the tool flags the messages they moved as missing. In Microsoft’s own words, “the result is perceived data loss rather than actual data loss, which makes it much harder to identify actual data loss during any content verification checks” (same page, checked September 6, 2026). That’s a vendor saying its process generates a fog of false alarms which hides the real ones. Someone works through that fog message by message, and that someone is billing by the hour.
Whole categories of thing the copy left where they were. Over IMAP, “Contacts, calendar items, and tasks can’t be migrated with IMAP; a user can manually migrate them” (Microsoft Learn, checked September 6, 2026). The user is you. That one clause is the afternoon you spent retyping an address book, and the meeting series that never came back.
The address had to be told where to go. “You need to change a DNS record called an MX record so that your email system can start routing mail to Office 365” (Microsoft Learn, checked September 6, 2026). One record changes once, and the delivery of every message the company receives changes with it. It’s the moment in the plan that feels irreversible. It’s why the whole thing was scheduled for a Friday evening.
And then the gap. “After the email migration is done, any new mail sent to the source email isn’t migrated” (Microsoft Learn, checked September 6, 2026). Between the last sweep of the old mailbox and the new destination taking effect everywhere, mail lands somewhere nobody looks again. You remember the rituals from that weekend. The freeze on sending. The note asking people to stay off email until Monday. The colleague still checking the old system two weeks later. Each one is a defense against that single sentence.
Practice makes it no cheaper. Fewer people do. Microsoft gives its own advice on the fastest of these methods. “With cutover migration, you can move up to 2,000 mailboxes, but due to length of time it takes to create and migrate 2,000 users, it’s more reasonable to migrate 150 users or less” (Microsoft Learn, checked September 6, 2026).
Add those up and look at what the list holds. Every item on it pays for two mailboxes ending up alike. You pay in provisioning, credentials, bandwidth, verification, retyping, a DNS change and a lost weekend. Sorting your mail sits outside that bill. So does finding anything, answering anyone, or saving you a minute of a working day. Remove the second mailbox and the bill stops being drawn up.
Two questions that separate the two cases
More than one vendor will tell you “no migration needed”, and two questions let you check it for yourself. You can answer both without knowing anything technical.
Where will my mail be next month? Not the app. The mail. If the honest answer names a company you don’t already pay for a mailbox, something has to be copied there. Everything in the section above then applies to you, whatever the marketing says. If the answer is the same Google or Microsoft account you have now, on the same plan and the same bill, the copy never happens.
Does anything change about where mail is delivered? A new address, a forwarding rule, an MX record, a redirect at your registrar. Any of those means you’re moving delivery, and delivery is the part with the risk in it. Leave all four alone and mail on the morning after arrives by the route it took this morning. The route stays exactly as it was.
Two smaller tells follow from the same distinction, and they’re useful in a demo. The first is what the thing asks you for. A migration wants passwords, because it has to open the source mailboxes and read them out. An app connecting to your account wants an authorization instead. You grant it on your provider’s own sign-in page, and you revoke it from your provider’s own settings. The app holds no password at all, which why Point never needs your email password takes apart properly.
The second is what happens to the old app. A migration ends with the source system being deliberately shut off, because two live mailboxes on one address is the failure it is designed to avoid. Change only the client and Gmail or Outlook is still sitting there tomorrow. It’s open in a tab, showing the same mail, agreeing with the new app. You can run both for a month. That’s simply what having a single mailbox means.
The wait that replaces the weekend
There’s one wait, and being straight about it matters more than minimizing it.
When you connect, a client reads back through what’s already in the account, and how long that takes depends on how much is in there. Eleven years of a busy mailbox takes a while. While it runs, the sorted view is partial. Sit and watch it fill and you’ll form a strong opinion of software that’s still thinking. Day one is about how to spend that hour, and what to hold off concluding from it.
The difference is what rides on it finishing. Every message stays in your mailbox the whole time. Mail that arrives in the middle is delivered by the same servers as always, and you read it right there. Deadlines stay out of it. People carry on sending. Close the laptop, come back tomorrow, and the only consequence is that you looked at it tomorrow. A migration weekend has a clock on it because mail can end up on the wrong side of a change. One mailbox has one side.
One question is worth putting to a vendor in advance, and it’s a product question rather than a safety one. Ask how far back the first pass reads, and whether search reaches the parts it has yet to read. The previous part makes the case for asking before you connect rather than in month two. The answer varies enough between products to be worth a sentence in an email.
The things that were never portable anyway
A short list stays behind, and there’s a surprise in it that is worth having.
Your signature is the main one. Any client-side rules you built stay behind with it, and so do any color categories you’d made your own. Setting those up again takes a few minutes, which is small enough that most pages mention it in passing and move on. It’s worth stopping on, because the same list stays behind in a real migration too.
Google publishes exactly what its migration tool carries between systems. The unsupported column includes “Rules (both server and client) or filters”, “Signatures”, “Category definitions or assignments”, “Importance levels of messages”, “Contact groups or personal distribution lists” and “Calendar permissions and sharing” (Google Workspace Help, checked September 6, 2026). Against filters, Google notes that you can build equivalent ones at the far end. Against signatures, that they can be re-created. Which is to say: retyped, by you, afterward, exactly as here.
So that residue costs the same either way. It’s a category of thing every migration has left behind, because of what it is. There’s a clean rule underneath, and once you have it you can place any item on any list yourself. If your provider’s server knows about it, it survives, because that server stays exactly where it is. If only your old app knew about it, it was a preference held inside a program, and preferences have always had to be set again.
Working out which of your own settings falls on which side of that line takes twenty minutes, and it’s best done before you connect. The checklist for it is how to switch to an AI email client. It covers rules that file things away in advance of any client seeing them, the other addresses your invoices go out from, a team address like accounts@ that nobody signs in to individually, and what to do about your phone.
When the real thing is the right answer
Some situations do need a migration, and this page leaves them exactly as they are.
If your address ends in the name of the company that sells you internet, you’re facing something else entirely. That mailbox ends when the service ends, and the copy you make while you still have access is the history you keep. It’s a real migration with a real deadline, and can you keep your email address sets it out in detail, including the order to do it in.
If you’re genuinely changing provider, everything itemized above is your project. That means off Google and onto Microsoft or the other way, or folding two Workspace accounts into one after an acquisition. Look for a guide written for that job. Budget more time than the estimate you were given. Treat the verification stage as the real work rather than the formality. Connecting a client leaves that project exactly where it is, and an honest client says so.
The same goes for mail that sits outside a live mailbox. An archive file on an old laptop. An export handed to you when you left a firm. A mailbox at a host you’re closing this month. Each one is a copy with a deadline attached, and it needs handling on its own terms. Connecting an app reaches into the account you connected, and only that.
What Point asks for instead
Point reads the mailbox you have. Whichever of Gmail or Microsoft 365 holds it, you sign in the way you already do, and after that Point is looking at that account in place. The whole of the setup is that sign-in. There’s no forwarding to arrange, no server settings to type, no file to export and none to import. Your address stays the address it was, and your provider carries on taking delivery, holding the mail and charging you for the mailbox. Your correspondents see what they saw last week, because on their side the day passed as usual.
What Point works out gets written back where your old app can read it. In Gmail that means three labels, Now, Later and Other. Each triaged message carries one of them, so a click inside Gmail itself narrows the mailbox to what needs you. In Outlook the same three are categories. Archive something in Point and the real mailbox archives it a second later, filed rather than deleted. Your contacts come with the connection, and the duplicates are merged. All of it lives in your own mailbox, annotated in vocabulary it already had.
How much Point handles is a level kept per kind of work. The three positions run from Point staying out of it, through Point preparing something for your approval, to Point doing that work itself. On the day you connect, every kind of work sits in that middle position. A running record lists what was done and when, in plain words, and an entry there can be reversed. The whole inventory is everything Point does. The positions and where each of them stops are the autonomy dial.
The limits belong in the same breath. Point works on an address you own, on mail that sits in the live account, and on a mailbox with an individual sign-in behind it. An address somebody else owns, an archive sitting on a disk, a team address with no individual sign-in behind it: those three stay somebody’s real moving job. Which client you read your mail in leaves that job exactly as it is.
The afternoon is one screen
That’s the whole of the answer to where the work went. It went into a problem that exists only when there are two mailboxes, and here there is one.
What’s left of the afternoon is smaller than this page. You sign in to your provider, on your provider’s own page, and you read one screen listing what an application is asking to reach. That screen is the agreement, and your provider writes it. Google’s version and Microsoft’s version ask for different things in different words. The two accounts behave differently once connected as well. That’s why the next two parts of this series are separate, rather than one page with a note in it.
Gmail first.