Many Philippine businesses still run email on an ageing local server, a hosting company's basic mailbox package, or a mix of free accounts that grew up as the team grew. It works until it doesn't: a mailbox fills up, a server fails, a departing employee takes access with them, or a client asks how you protect their data and nobody has a clear answer. Moving to Microsoft 365 solves many of these problems, but a rushed migration can lose email, break logins and leave staff frustrated for weeks.
This guide walks through a migration the way an experienced consultant would plan it: what to inventory first, how to choose a migration method, how to prepare and secure the new environment, how to cut over with minimal interruption, and what to do afterwards. It is written for owners and managers who may not do the technical work themselves but need to know what good looks like.
Step 1: Discovery and assessment
Most migration problems trace back to something nobody knew existed. Before choosing tools or dates, build a complete picture of what you have today.
- Mailboxes: every user mailbox, its approximate size, and who actually still uses it.
- Shared mailboxes: addresses such as sales@ or accounts@ that several people read.
- Distribution lists and aliases: group addresses and alternative addresses that forward to someone.
- DNS access: who controls your domain's DNS (the internet's address book for your domain) and whether you have the login. This is often the single biggest blocker.
- Licences: which Microsoft 365 plan each person needs, based on what they actually do.
- Devices: laptops, desktops and phones that will need reconfiguring.
- Third-party apps that send mail: accounting systems, scanners and printers that email documents, website contact forms, CRM tools and alarm systems. These are easily forgotten and quietly stop working after cutover.
Record this in a simple spreadsheet; it becomes your project checklist.
Step 2: Choose the right migration method
The right method depends on your source system and the size and complexity of your environment. There is no single correct answer, and anyone who recommends one without seeing your inventory is guessing.
If you are on Exchange on-premises
- Cutover migration: all mailboxes move in one go. Simpler, suited to smaller and less complex environments.
- Staged migration: mailboxes move in batches over a period. Useful where you need to spread the work out.
- Hybrid deployment: your local Exchange and Microsoft 365 run side by side for a time. More complex to set up, but suited to larger environments or where some mailboxes must stay local for a while.
If you are on Gmail or Google Workspace
Microsoft provides migration tooling in the Exchange admin center for Google Workspace, which can move mail and, depending on the approach, calendars and contacts. For simpler cases, an IMAP migration (copying mail over the standard IMAP protocol) can move email only.
If you are on a hosting company's mailbox
IMAP migration is usually the starting point. Check whether your provider limits IMAP connections, as this can slow large moves.
Step 3: Prepare and secure the tenant
Your "tenant" is your organisation's private space inside Microsoft 365. Prepare it properly before any mail moves, because security settings are much harder to introduce once people are already working in it.
- Verify your domain by adding the DNS record Microsoft provides.
- Assign licences according to your inventory.
- Turn on multi-factor authentication (MFA), which requires a second proof of identity such as an app prompt. Smaller organisations can use Security Defaults; organisations on suitable plans can use Conditional Access for more granular rules.
- Set up admin accounts properly: separate admin accounts from daily-use accounts, keep the number of global admins small, and keep a secured emergency ("break-glass") account.
- Review Exchange Online Protection, the built-in filtering for spam and malware.
- Configure SPF, DKIM and DMARC. These DNS records tell other mail systems which servers may send on your behalf (SPF), digitally sign your outgoing mail (DKIM), and say what to do with mail that fails those checks (DMARC). Together they reduce spoofing and help your mail land in inboxes rather than spam folders.
A few days before cutover, lower the TTL (time to live) on your MX records. TTL controls how long other systems cache your DNS settings. A lower value means that when you switch mail delivery to Microsoft 365, the change takes effect faster across the internet.
Step 4: Pilot, then migrate
Never move everyone at once without a test. Choose a small pilot group that includes a heavy email user and someone less technical. Migrate them first, let them work for a few days, and collect every issue. Fix the process, then proceed.
For the main migration, copy existing mail in the background while people keep working, then schedule the MX cutover (the DNS change that redirects incoming mail to Microsoft 365) for off-hours, such as a Friday evening or weekend. Run a final sync afterwards to catch anything that arrived during the switch. With good planning, interruptions can be kept minimal, but be honest with staff that there may be a short period of adjustment.
Step 5: Post-migration work
The migration is not finished when mail starts arriving. Plan time for:
- Outlook profiles on every computer, so desktop Outlook connects to the new mailbox.
- Mobile devices, removing old accounts and adding the new ones, ideally through the Outlook mobile app.
- Reconnecting third-party apps from your discovery list, such as scanners and accounting software.
- OneDrive, SharePoint and Teams adoption. Decide where files should live and how teams should share them, rather than letting everyone improvise.
- Retiring the old system only after verification. Keep it in read-only mode for a while so you can recover anything that was missed. Cancel the old service only once you are confident.
Common pitfalls to avoid
- Losing access to DNS at the critical moment because the domain is registered under a former employee or developer.
- Forgetting shared mailboxes and aliases, so important client email silently bounces.
- Skipping MFA "until later", which often means never.
- Missing SPF or DKIM updates, causing your outgoing mail to land in clients' spam folders.
- Switching off the old system on cutover day and discovering missing mail a week later.
Communication and training
Technical success means little if staff are confused on Monday morning. Send a short notice a week before cutover explaining what will change and when, a reminder the day before, and a one-page "first day" guide covering how to log in, set up MFA and add email to their phone. Nominate one person as the internal point of contact for questions. A short walkthrough of Teams and OneDrive in the first week pays off in fewer support requests later.
Key takeaways
- Inventory everything first, especially DNS access, shared mailboxes and apps that send email.
- Choose the migration method based on your source system and environment, not a default.
- Secure the tenant with MFA, proper admin accounts, SPF, DKIM and DMARC before moving mail.
- Pilot with a small group, cut over off-hours, and keep the old system read-only for a while.
- Communicate early and give staff simple first-day instructions.
Where to start
This week, confirm who holds your domain and DNS login and make sure the business, not an individual, controls it. Then build your inventory spreadsheet of mailboxes, shared addresses and devices. Once you can see the full picture, choosing a method and a cutover date becomes straightforward, and you can brief any provider with confidence.
If you would like an experienced second pair of eyes, Northgate IT Consultancy can review your current setup and migration plan through our Cloud & Infrastructure Review, or plan and carry out the migration as a scoped Build engagement. You can book a free 30-minute call to talk it through.