Moving the mailboxes is routine. The printers, the applications and the last server are what keep organisations stuck.
Mailbox migration is well understood and the tooling is mature. What causes an Exchange project to run long is everything attached to the mail platform that nobody documented: multifunction devices relaying scans, applications sending notifications through the internal server, delegation and shared mailbox arrangements built up over a decade, public folders somebody still uses, and the final on-premises server most organisations never manage to switch off. We scope those first.
- 3 pathsCutover, staged or hybrid
- SMTP relayThe commonest thing forgotten
- Public foldersWhere projects stall
- The last serverDecommissioning is a project
Eight workstreams, and mailboxes are only one of them.
Choosing the migration path
Cutover moves everything in a single event and suits small estates. Staged moves mailboxes in batches. Hybrid, configured through the Hybrid Configuration Wizard, keeps both environments live with shared mail flow and free/busy visibility, which is what larger organisations need and what carries the most configuration. The choice is driven by mailbox count, tolerance for a single cutover window, and whether you need coexistence for months rather than days.
Mailboxes, archives and the large ones
The mechanical part, and the edge cases are known: very large mailboxes, mailboxes with enormous item counts in a single folder, and on-premises archives that need a decision about whether they become online archives or are consolidated. Throughput is the planning variable, so measure it on a pilot batch rather than accepting a vendor figure, because Indian connectivity varies enough to matter.
Devices and applications relaying SMTP
The single most commonly forgotten item. Multifunction printers sending scans to email, line-of-business applications sending notifications, monitoring systems, backup software and anything else pointed at the internal Exchange server. These fail silently after cutover, and the failure surfaces days later when somebody notices the scan-to-email nobody uses daily has stopped. Inventory them by examining actual connection logs rather than by asking.
Shared mailboxes, delegation and permissions
A decade of accumulated full access, send-as and send-on-behalf permissions, folder-level delegation, and calendar permissions that people rely on daily without being able to describe. These matter enormously to the individuals affected and are invisible to anybody else, which is why the complaints arrive within an hour of cutover. Export the full permission set before the move and validate it after.
Public folders, which stall more projects than anything else
Still in use in a surprising number of Indian organisations, frequently holding shared calendars and contact lists that a department depends on. Migration to Exchange Online public folders or to shared mailboxes and Teams is a genuine decision with a genuine effort attached, and it is where projects most often stop. Scope this honestly at the start, because discovering the extent of public folder use halfway through is a schedule event.
Mail flow, hygiene appliances and authentication
What sits in front of your mail today, whether that is an appliance, a cloud filtering service, or a chain of both, and whether it stays. The migration is also the right moment to get SPF, DKIM and DMARC correct, because mail flow is changing anyway and DMARC enforcement is far easier to introduce during a planned change than as a separate project later.
Journaling, retention and legal hold
Organisations with an on-premises journaling arrangement or a third-party archive need a target position before mailboxes move, not after. Exchange Online retention policies, litigation hold and the wider Purview compliance surface do the job differently, and regulated organisations frequently need the change documented for an auditor rather than merely implemented.
Decommissioning the last Exchange server
Where most organisations stop. Directory synchronisation through Entra Connect means recipient attributes are managed on premises, which historically required keeping one Exchange server for management tooling. Getting to a genuinely Exchange-free estate is a defined piece of work with prerequisites, and leaving that server running indefinitely means continuing to patch and secure an internet-adjacent mail server you no longer use.
Eight failures we plan around, and how each one surfaces.
Scan-to-email stops working
The multifunction devices were configured years ago against the internal server address by whoever installed them, and nobody has touched the settings since.
- Find them in connection logs, not by asking the facilities team
- Decide between direct send, SMTP relay and a connector per device type
- Test each device model, since firmware differs in what it supports
Applications stop sending notifications
The ERP, the ticketing system, the monitoring platform and the backup software all send mail through the internal server, and none of them raise an alarm when they cannot.
- Silent failure is the danger, since nobody notices absent alerts
- Authenticated submission is generally the right answer for applications
- Some legacy applications cannot do modern authentication and need a connector
Somebody loses access to a shared mailbox
Full access, send-as and send-on-behalf built up over years, held by people who cannot describe the arrangement but notice its absence immediately.
- Export the complete permission set before migrating anything
- Validate against that export after each wave rather than waiting for reports
- Folder-level and calendar permissions are separate and get missed
A department discovers its public folder is gone
Shared calendars and contact lists in public folders that a specific team depends on daily, invisible to everybody else and unmentioned in any inventory.
- Report on public folder access before assuming they are unused
- Shared mailboxes or Teams are usually a better target than public folders
- Migrate the ones in use and archive the rest, deliberately
External mail starts going to junk
Mail flow changes and SPF, DKIM or DMARC do not keep up, so outbound mail from the new platform or from a third-party sender fails authentication.
- Update SPF before cutover, and check every third-party sender
- Enable DKIM signing on the accepted domains in Exchange Online
- Move DMARC toward enforcement during the change rather than afterwards
The cutover window overruns
Throughput assumed rather than measured, so the batch that was supposed to finish overnight is still running when people arrive.
- Measure real throughput on a pilot batch and plan from that number
- Pre-seed content well ahead, leaving only a delta pass for the window
- Size waves so any single one fits comfortably inside the window
Free/busy stops working during coexistence
The hybrid configuration is incomplete or a certificate or endpoint is wrong, so migrated and unmigrated users cannot see each other availability.
- Test cross-platform free/busy in both directions before the first wave
- Certificates and published endpoints are the usual culprits
- This is the coexistence failure users report fastest
The last server never gets switched off
The mailboxes moved years ago and one on-premises Exchange server is still running, still needing patching, and still presenting an attack surface for a service nobody uses.
- Plan decommissioning as part of the project, not as a later intention
- Understand the recipient management prerequisites before starting
- An unpatched internet-adjacent mail server is a real and recurring risk
We scope the attachments, not just the mailboxes.
We find the SMTP relay traffic from logs
Asking which devices and applications send mail produces an incomplete list every time, because nobody knows about the ones configured years ago by somebody who has left. Examining actual connection logs on the existing server produces the real list, and that is the difference between a clean cutover and a fortnight of small failures.
We export and verify permissions rather than trusting the move
Shared mailbox access and delegation matter enormously to the people who use them and are invisible to everybody else. We take a complete permission export before anything moves and validate against it after each wave, so problems are found by us rather than reported by an executive.
We use the change to fix mail authentication
Mail flow is changing anyway, which makes it the cheapest moment you will ever get to correct SPF, enable DKIM and move DMARC toward enforcement. Doing it as part of the migration costs almost nothing extra; doing it as a separate project later means changing mail flow twice.
We plan the decommissioning, including the last server
A migration that leaves an unpatched Exchange server running has not finished. We scope decommissioning as a deliverable with prerequisites and a date, and where it genuinely has to stay we make sure it is properly controlled rather than merely forgotten.
Why organisations finally move.
A version reaching end of support
The most common trigger, with a hard date and a security argument attached. Also the situation with the least room to defer, which makes early scoping of the awkward items more valuable rather than less.
Hardware or a datacentre lease ending
Frequently part of a wider Azure or datacentre exit programme, which means mail is one workstream among several and the sequencing between them matters.
BFSI and regulated organisations
Journaling, retention and legal hold need a target position agreed and documented before mailboxes move, and the change usually has to be evidenced for an auditor rather than merely completed.
GCCs aligning with a parent
A group standard requiring the Indian entity to move into a shared tenant, which brings tenant-to-tenant considerations alongside the on-premises migration.
Manufacturing with heavy device dependency
Plants full of multifunction devices, quality systems and shop-floor applications sending mail. The relay inventory is the whole project here, and it is invariably longer than expected.
Education with large user counts
High mailbox counts, seasonal load, and heavy use of shared calendars and distribution lists. Usually hybrid, and usually paced around term dates rather than around technical readiness.
Where each kind of sender should go after cutover.
| Sender type | Recommended approach | Why, and what to watch | |
|---|---|---|---|
| Modern applications that can authenticate | Authenticated submission with a dedicated account | The cleanest option. Use a separate identity per application so a compromised credential can be revoked without affecting anything else, and so the sending is attributable. | |
| Multifunction printers and scanners | Direct send, or a connector where the device cannot authenticate | Test each model rather than one, since firmware differs in what authentication it supports. Older devices frequently cannot do modern authentication at all. | |
| Legacy line-of-business applications | A connector restricted to known source addresses | The fallback where the application cannot be changed. Restrict tightly by source address, because an open relay path is exactly what attackers look for. | |
| Monitoring and backup systems | Authenticated submission, and test the failure path | These fail silently and their whole purpose is to tell you when something is wrong, so verify after cutover by deliberately triggering an alert rather than assuming. | |
| Internal-only notifications | Direct send is usually sufficient | Simplest where mail never leaves the organisation. Confirm the recipients really are all internal, since a single external recipient changes the requirement. | |
| High-volume marketing or transactional mail | A dedicated sending service, not your mail platform | Keep bulk sending off the platform your business mail depends on, so a reputation problem with one does not affect the other. Update SPF for whichever service you choose. |
Cutover, staged and hybrid, and which fits.
| Feature | Dimension | Cutover | Hybrid |
|---|---|---|---|
Suits | Smaller estates with a tolerable single window | Larger estates, or anyone needing months of coexistence | |
Coexistence | None, it is a single event | Full, with shared mail flow and free/busy | |
Configuration effort up front | Modest | Substantial, via the Hybrid Configuration Wizard | |
Free/busy during the move | Not applicable | Works, if configured and tested properly | |
Risk profile | Concentrated into one night | Spread across waves, with more moving parts | |
Rollback | Harder, since it is a single transition | Easier, since unmigrated users are unaffected | |
On-premises servers after | Can usually be retired sooner | Retirement is a separate planned exercise | |
Typical duration | Days to a few weeks | Weeks to months, paced to your support capacity |
Plan to switch the last server off, or you will still be patching it in three years.
A large number of Indian organisations completed their Exchange Online migration years ago and still run one on-premises Exchange server, because directory synchronisation meant recipient attributes were managed on premises and the management tooling lived there. That server still needs patching, still needs securing, and is exactly the class of internet-adjacent system that has been targeted repeatedly. Getting to a genuinely Exchange-free estate has defined prerequisites and is achievable, and it belongs in the project scope rather than in a follow-up nobody funds.
- Treat decommissioning as a deliverable with a date, not an aspiration
- Understand the recipient management prerequisites before the migration starts
- An unused mail server is not a dormant risk, it is an unmonitored one
- If it genuinely must stay, put it behind proper controls and patch it on a schedule
Five stages, and the inventory is the one that saves you.
- 1
Assess the estate and everything attached to it
Mailbox count and sizes, archives, public folder usage measured rather than assumed, distribution and dynamic groups, a complete permission export, and above all the connection log analysis that produces the real list of devices and applications relaying mail. This inventory is what determines whether the project runs to plan.
- 2
Choose the path and design the target
Cutover, staged or hybrid, decided on mailbox count and coexistence need rather than on preference. Target retention, archive and legal hold position agreed, particularly where journaling exists today. Mail hygiene decisions made, and the SPF, DKIM and DMARC target position defined.
- 3
Prepare, configure and pilot
Hybrid configured and free/busy tested in both directions if coexistence applies, relay approach implemented and tested per device type, and a pilot group run for a full week including whatever periodic processes matter. Throughput measured on that pilot so the wave windows are planned from a real number.
- 4
Migrate in waves, validating permissions after each
Content pre-seeded ahead of each wave with a delta pass in the window, waves grouped by team so people who share mailboxes and calendars move together, and permission validation against the pre-migration export after every wave rather than at the end.
- 5
Decommission properly, including the last server
Mail flow cut over fully, third-party appliances removed from the path where they are no longer needed, archive and retention confirmed in the target, and the on-premises Exchange environment decommissioned including the final server. Then handover, or ongoing management.
Twelve checks before you move a production mailbox.
What connects to mail
- Every device relaying SMTP identified from connection logsPrinters, scanners, door systems, anything
- Every application sending mail identified and repointedThey fail silently, which is the danger
- A relay approach chosen per sender typeDirect send, authenticated submission or a connector
- Each device model tested, not just oneFirmware support for authentication differs
Mailbox configuration
- Full permission export taken before anything movesFull access, send-as, send-on-behalf, folder level
- Shared mailboxes and distribution groups inventoriedIncluding dynamic groups and their filters
- Public folder usage measured rather than assumedWhere projects most often stall
- Archive and retention target position agreedEspecially where journaling exists today
Mail flow
- SPF updated for the new sending path and all third partiesThe commonest cause of post-cutover junk folder issues
- DKIM signing enabled on every accepted domainCheap, and frequently skipped
- Hybrid free/busy tested in both directionsIf you are running coexistence at all
- Throughput measured on a pilot batchPlan windows from that number, not from a datasheet
Exchange migration, answered plainly.
What sits either side of this.
Google Workspace to Microsoft 365
The other route into Exchange Online, where mail is the easy half and Drive conversion decides the schedule.
Learn moreEmail security audit
SPF, DKIM and DMARC reviewed and moved toward enforcement, which is far cheaper to do during a migration than after one.
Learn moreTenant to tenant migration
The other mail migration problem, for mergers, divestitures and group consolidations where both sides are already in Microsoft 365.
Learn moreOfficial documentation
- Ways to migrate multiple email accounts to Microsoft 365, Microsoft Learn
- Exchange Online documentation, Microsoft Learn
Start with the inventory of what talks to your mail server.
Mailboxes are predictable. The relay traffic, the public folders and the permission set are what determine whether this runs to plan, and pulling that inventory takes days rather than weeks. Remote-first from Hyderabad, serving all of India.
Related Services
Explore more solutions that work great with this service