Microsoft 365 Migration Checklist for Hong Kong Businesses

The short answer: A Hong Kong Microsoft 365 migration runs in five phases — assess your current environment, choose the right license tier, pilot with a small group, execute the cutover (staged or hybrid-coexistence, rarely a single "big bang"), then harden security immediately after go-live. The single most common mistake is treating security baselining — MFA, conditional access, mailbox rules review — as a post-migration nice-to-have instead of a pre-cutover requirement; that gap is exactly the window attackers exploit during a migration window.

If your Hong Kong business is planning a move to Microsoft 365 — from an on-premise Exchange server, from Google Workspace, or consolidating a messy multi-tenant setup left over from a merger or acquisition — this guide is different from our Microsoft 365 Optimisation in Hong Kong 2026 guide, which is written for businesses already on M365 looking to improve hybrid-work productivity and cost efficiency. This guide is for the earlier decision point: planning and executing the migration itself, safely and with minimal disruption, before optimisation even becomes a relevant question.

Pre-Migration Assessment: What to Inventory Before You Touch Anything

Every migration that goes badly starts the same way — someone begins moving mailboxes before anyone has a complete picture of what's actually in the current environment. A proper pre-migration assessment inventories every mailbox and its size, every distribution list and shared mailbox, every third-party application that integrates with your current email or directory (CRM connectors, accounting software, e-signature tools), every device that will need reconfiguring, and every custom mail-flow rule or transport rule that quietly does something important nobody remembers setting up. For a Hong Kong business specifically, this is also the point to document any Chinese-language mailbox naming conventions, any bilingual distribution lists, and any integration with locally-used tools (WhatsApp Business API bridges, Alipay/WeChat Pay notification routing, or China-side systems if you operate a mainland office) that a generic migration checklist written for a Western market would never surface.

Choosing the Right License Tier

Microsoft 365 licensing is genuinely confusing, and picking the wrong tier is one of the most common and most expensive migration mistakes — either overpaying for E5-tier security features a 15-person office will never configure properly, or underpaying on Business Basic and discovering six months later that a compliance requirement needs a feature that isn't in the plan. The right approach is to map your actual requirements first: do you need on-premise Exchange hybrid coexistence during a staged migration (this usually requires at least Business Standard or higher, and Exchange Online Plan licensing for shared/resource mailboxes); do you have a genuine compliance driver — PDPO, an industry regulator, a client contract clause — that specifically requires Advanced Threat Protection, Data Loss Prevention, or eDiscovery capabilities found only in E5 or added as an add-on; and how many of your users are true frontline/task workers who need only mail and Teams versus knowledge workers who need the full desktop application suite. Getting this mapping right before migration, not after, avoids an expensive mid-project licensing change.

Migration Approach: Cutover, Staged, or Hybrid Coexistence

There are three broad migration patterns, and the "big bang" cutover — moving everyone in one weekend — is the riskiest and least common in practice for any office beyond a handful of users. A cutover migration moves all mailboxes at once, typically over a weekend, and works reasonably well only for very small organisations (commonly cited as suitable below roughly 150 mailboxes) with a simple environment and low tolerance for a multi-week project. A staged migration moves users in batches over days or weeks — department by department, or by seniority/risk tolerance, moving a pilot group first — which spreads support load and lets you catch configuration problems on a small group before they affect everyone. A hybrid coexistence migration keeps your on-premise Exchange server and Microsoft 365 running side by side for an extended period, with mail flowing correctly between both, which is the right choice for larger or more complex environments, businesses with regulatory reasons to keep some mailboxes on-premise longer, or any migration where a clean cutover weekend simply isn't realistic given the number of integrations involved. For most Hong Kong SMEs moving from an ageing on-premise server or a messy multi-tenant Google Workspace setup, a staged migration over two to four weeks is the most common and most manageable pattern in practice.

Security Baseline Before Go-Live — the Step Most Migrations Skip

This is the section worth reading twice, because skipping it is the single most common and most damaging migration mistake we see. A newly provisioned Microsoft 365 tenant, by default, does not have multi-factor authentication enforced, does not have conditional access policies configured, and does not have mailbox forwarding rules locked down — which means the tenant is at its most vulnerable during the exact window when user credentials, old passwords, and legacy authentication protocols are all still being sorted out. Before a single mailbox goes live for real use, MFA should already be enforced for every account (ideally via Conditional Access rather than legacy per-user MFA, which is easier to bypass), legacy authentication protocols that don't support MFA should be blocked at the tenant level, and auto-forwarding rules to external addresses should be disabled by default and only re-enabled with a specific business justification. This isn't paranoia — attackers actively scan for newly created Microsoft 365 tenants specifically because migration windows are a known soft spot, and a compromised mailbox discovered after go-live is a dramatically more expensive problem to unwind than a day of extra security configuration before cutover.

PDPO Considerations During the Migration Window

Hong Kong's PDPO framework applies to personal data throughout a migration, not just once it lands in its final location — which matters because a migration project inherently moves data through intermediate states (export files, migration tooling, temporary staging areas) that need the same handling discipline as the production system. Practically, this means confirming where Microsoft 365 data actually resides (Microsoft's Asia-Pacific datacentre regions, and understanding Microsoft's own data-residency commitments for your specific tenant configuration), ensuring any migration vendor or tooling used has an appropriate data-processing agreement in place, and making sure exported PST files or other intermediate data dumps used during migration are encrypted and deleted on a defined schedule rather than left sitting on a migration engineer's laptop indefinitely. None of this should meaningfully slow down a well-planned migration — it's a documentation and process discipline, not a technical blocker — but it's the kind of detail that's easy to skip under project-deadline pressure and expensive to explain after the fact if a client or regulator asks.

Post-Migration: Adoption and Ongoing Support

The migration project isn't finished when the last mailbox is moved — user adoption and a support runway for the first few weeks matter as much as the technical cutover itself. Staff who've used the same email client or file-sharing habit for years need genuine, hands-on guidance on where files now live (SharePoint/OneDrive versus a mapped network drive), how Teams changes day-to-day collaboration, and what's different about the new mobile mail experience — a well-run migration budgets for this adoption period explicitly rather than assuming users will figure it out. This is also the point where the migration project should hand off cleanly into ongoing operational support: monitoring mail flow, managing licenses as headcount changes, keeping security policies current, and being the first call when something in the new environment doesn't behave the way the old one did. Brocent's managed IT and cloud services cover exactly this handoff, and our Microsoft 365 Optimisation guide is the right next read once you're past migration and into ongoing hybrid-work optimisation.

What a Realistic Project Team and Timeline Actually Looks Like

Migrations that stay on schedule tend to share a common structure: a named project lead on both sides (not "IT will handle it" with no single accountable owner), a defined pilot group of 5-10 users who go first and surface real-world issues before the rest of the business is affected, and a written rollback plan for each cutover batch in case something goes wrong mid-migration — not because it usually does, but because having the plan already written removes the pressure to improvise under stress. A realistic week-by-week shape for a 50-person staged migration looks roughly like: week one for assessment and license procurement; week two for pilot-group migration and security baseline configuration; weeks three and four for the remaining batches, department by department; and a final week for stabilisation, adoption support, and closing out any lingering integration issues. Compressing this timeline under pressure to hit an arbitrary deadline is one of the more common ways security hardening or proper testing gets quietly skipped.

Common Pitfalls Beyond Security: Bandwidth, Legacy Apps, and Communication

Security gets (rightly) the most attention, but three other pitfalls sink otherwise well-planned migrations often enough to be worth naming directly. The first is internet bandwidth underestimation — bulk mailbox uploads to Microsoft's cloud and, separately, everyone downloading OneDrive/SharePoint content for the first time, can saturate an office's internet connection in ways a business never noticed before, because day-to-day usage rarely pushes bandwidth this hard; testing actual throughput against expected migration volume before the project starts avoids a nasty surprise mid-cutover. The second is legacy line-of-business application compatibility — older accounting packages, industry-specific software, or anything that authenticates against an on-premise Active Directory or an old POP/IMAP mail integration can break silently when the mail backend changes underneath it, and these integrations are exactly the kind of thing a rushed inventory misses. The third, and most underestimated, is internal communication about the change itself — staff who hear about a "migration" only the week it happens, with no context for why file locations are changing or why they suddenly need to re-authenticate everywhere, generate a spike of confused support tickets that a short heads-up email and a one-page FAQ would have prevented entirely.

DIY/In-House vs Vendor-Led One-Time Project vs Managed IT Partner

• DIY / In-House Migration — Lowest direct cost if you already have capable internal IT staff; highest risk of the security-baseline and PDPO-in-transit gaps described above being missed under project-deadline pressure, since most in-house teams run only one or two migrations in their career and lack the repeated-pattern experience a specialist has.
• Vendor-Led One-Time Migration Project — A specialist executes the technical cutover competently, but the engagement typically ends at go-live — leaving the adoption-support gap and the ongoing operational handoff (license management, security policy upkeep, day-to-day Teams/Teams solutions support) for someone else to pick up afterward, often with no continuity of institutional knowledge about how your specific tenant was configured.
• Managed IT Partner (Brocent's model) — The same team plans and executes the migration and then continues as your ongoing managed IT and cloud services and security provider — meaning the security baseline set at go-live is actually maintained afterward, adoption support continues past week one, and there's a single point of accountability rather than a handoff between two vendors.

Frequently Asked Questions

How much downtime should we expect during a Microsoft 365 migration?

With a staged or hybrid-coexistence approach, planned downtime should be minimal to zero for most users — mail continues flowing throughout, and individual mailboxes are cut over in scheduled batches, typically outside peak business hours. A cutover-style migration for a very small office may involve a short planned outage window, usually communicated and scheduled for a weekend, but this is increasingly rare as a deliberate choice for anything beyond the smallest teams.

We're moving from Google Workspace, not an on-premise server — is the process different?

The underlying phases are the same — assessment, licensing, pilot, cutover, security hardening — but the technical tooling differs, and specific attention is needed for Google-specific artifacts: shared Drive structures, Google Groups mapping to Microsoft 365 distribution lists or groups, and calendar/contact migration behaviour, which works differently than an Exchange-to-Exchange move. Budget extra assessment time specifically for how your team's Google Drive sharing structure will map onto SharePoint/OneDrive permissions, since this is the area most often underestimated in Workspace-to-M365 projects.

Does data leave Hong Kong during the migration, and does that create a PDPO problem?

Data does pass through Microsoft's cloud infrastructure as part of any Microsoft 365 migration, since that's inherent to the service — the PDPO-relevant question is less "does it leave Hong Kong" and more whether your organisation has appropriate agreements and documentation in place regarding Microsoft's data handling and residency commitments for your tenant, and whether any migration-specific intermediate data (export files, migration logs) is handled with the same care as production data. This is a solvable documentation and process question, not a reason to avoid Microsoft 365.

How long does a typical migration take for a 50-person Hong Kong office?

For a moderately complex 50-person environment with typical email volumes and a handful of integrations, a staged migration commonly runs four to eight weeks from initial assessment through final cutover and a stabilisation period — shorter for a clean, simple environment, longer if there's a messy multi-tenant history, significant custom mail-flow rules, or extensive third-party integrations to remap.

What's the biggest security risk specifically during the cutover window?

The two biggest risks are a newly provisioned tenant without MFA/conditional access enforced yet (an easy target for credential-stuffing attacks specifically because it's new and not yet hardened), and legacy authentication protocols left enabled during the transition period for compatibility with older devices or applications — both of which should be closed before go-live, not treated as "we'll tighten this up later" items.

Who should actually run a Microsoft 365 migration — our internal IT person, or a specialist?

For a small, simple environment with a competent internal IT person who has planned a migration like this before, in-house execution is workable. For most Hong Kong SMEs, the higher-risk items — security baseline sequencing, PDPO-in-transit handling, and the specific quirks of your particular source environment — benefit from a provider who has run this exact type of migration repeatedly, which is where the real risk reduction (not just convenience) of a managed partner comes from.

We're consolidating two Microsoft 365 tenants after an acquisition — is that a different kind of project?

Yes, meaningfully — a tenant-to-tenant migration (moving one company's Microsoft 365 environment into another's, or merging both into a fresh third tenant) carries all the same phases described above, plus cross-tenant identity mapping, domain and DNS cutover planning, and a harder question of whose security baseline, naming conventions, and governance policies win when the two environments genuinely conflict. This is one of the more complex migration scenarios in practice and benefits especially strongly from a provider who has actually run tenant consolidations before, rather than only single-source migrations.

How much does a Microsoft 365 migration project typically cost in Hong Kong?

Cost depends primarily on mailbox count, environment complexity (how many custom mail-flow rules, third-party integrations, and legacy applications need remapping), and whether you also need security-baseline configuration and post-migration adoption support bundled in versus a bare technical cutover only. Rather than quote a generic figure that won't reflect your specific environment, Brocent's pricing page outlines how managed IT and cloud-migration engagements are structured, and a proper quote should follow the pre-migration assessment once your actual mailbox count and integration list are known.

Will our older accounting or industry-specific software still work after migration?

Usually yes, but this is exactly the category of risk that needs checking before, not after, cutover — any application that authenticates against your old on-premise directory, connects via POP/IMAP, or was configured years ago by someone no longer at the company needs to be explicitly identified and tested during the pre-migration assessment. This is one of the most common sources of a post-migration "why did this suddenly stop working" support call.

Do we need to warn staff before the migration happens, or can IT just handle it quietly?

Warn them, clearly and early. A migration that lands as a surprise generates a wave of confused tickets in the first week — "where did my files go," "why am I being asked to log in again" — that a short advance notice and a one-page changes summary largely prevents. Treating the migration as a purely technical project rather than a change-management one is a common and avoidable mistake, especially for offices where English isn't every employee's first working language and a Cantonese or Mandarin explanation genuinely helps adoption.

Planning Your Migration

A Microsoft 365 migration is a project with a real risk profile, not a routine IT task — the businesses that get it wrong almost always skipped the same step: treating security hardening as something to circle back to after go-live rather than a pre-cutover requirement. The good news is that none of the risks covered in this guide are exotic or hard to plan around once you know to look for them; a proper inventory, the right license mapping, a sensible staged or hybrid-coexistence approach, a hardened security baseline before cutover, and honest attention to PDPO handling of data in transit cover the large majority of what actually goes wrong in practice. Brocent plans and executes Microsoft 365 migrations for Hong Kong businesses end to end — cloud migration and managed services, security hardening, and Teams and collaboration setup — and stays on as your ongoing managed IT partner once the migration itself is done, rather than handing you off at go-live. See our pricing for typical project scope, or get in touch to talk through your specific environment.