How MSPs Migrate Client Tenants with EdbMails

If you're an MSP or an independent IT consultant, Office 365 migrations are probably a recurring part of your work — a client signs on, you assess their environment, and you run the migration on their behalf, usually with their explicit authorization and admin access. EdbMails Office 365 Migration fits naturally into this kind of engagement: you install it once on your own working machine, connect it to your client's source and target tenants using the access they grant you, and run the migration project the same way you would for your own organization — just on someone else's environment.

This isn't a centralized "manage twenty clients from one dashboard" tool, and it's worth being upfront about that. What EdbMails does well for consultants is make each individual client engagement clean, repeatable, and low-friction, so you're not relearning a new process — or fighting PowerShell scripts — every time a new client comes through the door.

Here's how that actually plays out in practice.

Setting Up Before You Touch a Client's Tenant

Before you connect to anything, get the access sorted properly. You'll need either Global Administrator credentials or a delegated admin account on both the source and target tenants — most clients prefer issuing a scoped admin account specifically for the migration rather than handing over their primary global admin login, and that's a reasonable practice to encourage. EdbMails authenticates using OAuth 2.0 modern authentication, so you're never handling or storing raw passwords; the client authenticates directly through Microsoft's own sign-in page, which is also reassuring for clients who are (rightly) cautious about handing third-party tools broad access to their tenant.

Install EdbMails on your own machine — not the client's — so you have a consistent, known environment to run migrations from across engagements. Since EdbMails is a Windows desktop application, make sure your working machine meets the system requirements before you're on a call with a client expecting things to move quickly.

Running the Migration for a Client Engagement

Once access is set up, the workflow is the same one you'd use for a single-tenant migration, just pointed at your client's environment instead of your own. In brief:

1. Connect to the client's source tenant (another Office 365 tenant, on-premise Exchange, IMAP, G Suite, or hosted Exchange) and authenticate.
2. Connect to the target Office 365 tenant the same way.
3. Let EdbMails auto-map mailboxes between source and target, or load mappings via CSV for custom cases.
4. Create target mailboxes and assign licenses automatically if they don't already exist.
5. Select the mailboxes, folders, or filters to migrate, then start the transfer.
6. Validate item counts and review the migration report before handing off to the client.

For the full walkthrough with screenshots and configuration details, see the Office 365 Migration Guide.

For client engagements specifically, a few features matter more than they might for an internal migration:

CSV-based mapping is useful when a client's naming conventions on the source don't cleanly match what they want on the target — common in mergers, rebrands, or domain changes, which is a frequent reason clients bring in outside help in the first place.

Incremental migration means that if a client's migration needs to happen in stages — say, a pilot batch of a few mailboxes first, followed by the rest of the organization later — re-running the migration won't create duplicates. Only new or changed items get picked up on each subsequent pass, which is exactly the kind of staged rollout many clients prefer over a single risky cutover weekend.

Concurrent mailbox migration lets you move multiple mailboxes in parallel rather than one at a time, which matters a lot when a client engagement has a fixed window — a weekend cutover, for instance — and you need to get through dozens or hundreds of mailboxes before Monday morning.

Filtering options (by date range, sender, recipient, folder, or subject) help when a client only wants specific data migrated — common in compliance-sensitive engagements where not everything from the old environment should carry over.

Handling Licensing Across Multiple Client Engagements

Licensing is per source mailbox, not per migration run or per destination — so if you're migrating the same 50 mailboxes for a client, re-running that migration (say, to catch newly arrived items before final cutover) doesn't consume additional licenses. This matters for consultants because it means you can safely run a pilot migration, validate it with the client, and then run the full incremental pass without worrying about double-counting against the license you purchased for that engagement.

Since each client engagement is its own project with its own source and target, keep your license usage organized per client — EdbMails' license usage screen lets you check how many mailboxes have been used against your total purchased count, which is worth reviewing before starting a new client engagement if you're working across several licenses.

Closing Out a Client Engagement Properly

Before you consider a client migration complete, validate it the same way you would for your own organization: confirm item counts match between source and target, check that calendar and contact data transferred correctly, and review EdbMails' migration reports, which log the full operation in detail. These reports are also genuinely useful to hand to a client directly — having a documented, exportable record of exactly what was migrated gives the client (and you) a clean paper trail if questions come up later.

Once validation is confirmed and the client has cut over to the new environment, your engagement-specific work is done. Because EdbMails doesn't retain stored credentials and each engagement is self-contained, there's no lingering access or open connection left behind once you've wrapped up — which is a reasonable thing to confirm explicitly with risk-conscious clients.

What This Approach Is — and Isn't

To be clear about scope: this is a per-engagement workflow, not a centralized multi-client management platform. If you're running migrations for ten clients in a given month, you'll be setting up and running ten separate engagements rather than monitoring all of them from a single shared dashboard. For most independent consultants and smaller MSPs, that's a perfectly workable model — each engagement gets the same clean, repeatable process, and the lack of PowerShell scripting means you're not maintaining custom automation per client either.

The Bottom Line

EdbMails works well for MSPs and IT consultants who run Office 365 migrations as part of client engagements, provided you understand the model: install it once on your own machine, get proper delegated or admin access per client, run the migration the same straightforward way you would for any single tenant, and validate before closing out. It won't manage a dozen client projects from one shared console, but for consultants handling migrations one client engagement at a time, it removes the scripting overhead and gives you a repeatable process you can bring to every new client without reinventing it.

---

Additional resources:

• Office 365 Migration Guide
• EdbMails Office 365 Migration FAQs
• Office 365 Migration User Manual
• Exchange to Office 365 Migration Using EdbMails
• Office 365 Migration System Requirements