DEV Community: Manoj Dwivedi

Delegated vs App-Only Auth in Microsoft 365 Migrations (Hard Lessons)

Manoj Dwivedi — Thu, 08 Jan 2026 11:34:50 +0000

If you’ve ever built a Microsoft 365 migration script, chances are you started with delegated authentication.

I did too.

It’s quick to set up, easy to debug, and works fine for a handful of users. The problem is that delegated auth has a habit of failing only after you trust it — usually halfway through a long-running migration.

This post isn’t about what Microsoft recommends. It’s about what breaks in real tenant-to-tenant migrations and why app-only auth eventually becomes unavoidable.

Why Delegated Auth Feels Like the Right Choice (At First)

Delegated auth is appealing because it feels familiar:

Sign in as admin
Consent permissions
Run the script
Watch data move

For POCs and demos, it works surprisingly well. That’s why so many migration scripts online are built this way.

The trouble starts when:

Jobs run for hours
You add concurrency
You migrate more than a few dozen users

That’s when delegated auth shows its real limitations.

The First Failure Is Usually Silent

The first time delegated auth fails, it often doesn’t throw a clean error.

Instead, you’ll see things like:

Requests suddenly returning 401
Token refresh loops
Background jobs stopping without obvious logs

What actually happened?

The session expired
MFA kicked in
The refresh token became invalid
The user context was no longer trusted

None of these are easy to diagnose mid-migration.

User-Based Throttling Is a Hidden Problem

Delegated auth ties every request to a user identity.

That means:

You hit user-based throttling faster

Parallelism collapses under load

Retry storms become more likely

In one migration, we increased concurrency to speed things up and actually made it slower. Requests started backing off constantly because everything was bound to a single admin user.

At that point, no amount of retry logic helps.

Background Jobs and Delegated Auth Don’t Mix

Tenant migrations are not interactive tasks.
They:

Run overnight

Span days

Resume after failures

Require retries long after the original process started

Delegated auth assumes there’s a user session somewhere behind the scenes.

App-only auth doesn’t.

This difference alone is enough to rule out delegated auth for serious migrations.

App-Only Auth Is Boring — and That’s a Good Thing

Once you switch to app-only authentication, something interesting happens: things get boring.

No pop-ups.
No session expiry.
No MFA surprises.

You get:

Stable tokens
Predictable throttling behavior
Clean separation between identity and execution It’s not flashy, but it’s reliable — which is exactly what migrations need.

Permissions Are Scarier, but More Honest

One valid concern with app-only auth is permission scope. Granting tenant-wide permissions feels dangerous, and it should.

But here’s the uncomfortable truth:
If you’re migrating tenant data at scale, you already need broad access.

Delegated auth doesn’t make that safer — it just hides it behind a user account.

With app-only auth:

Permissions are explicit
Access is auditable
Rotation is easier
Responsibility is clearer

That’s a better security posture, not a worse one.

Retry Logic Behaves Differently (and Better)

This was an unexpected benefit.

With delegated auth, retries often fail for reasons unrelated to load:

Token refresh failures
Session invalidation
Conditional access policies

With app-only auth, retries usually fail for real reasons:

Throttling
Temporary service issues
That makes retry logic simpler and more predictable.
When Delegated Auth Is Still Okay

Delegated auth isn’t useless. It’s fine for:

One-off admin tasks
Small migrations
Validation scripts
Exploratory tooling

The mistake is assuming it will scale just because it worked once.

The Rule I Follow Now

My rule of thumb is simple:

If the process needs to survive a restart, it should not depend on a user session.

Tenant-to-tenant migration definitely falls into that category.

Final Thoughts

Most migration failures don’t come from bad code.
They come from wrong assumptions.

Delegated auth assumes:

Short execution
Stable sessions
Low concurrency

Tenant migrations assume none of those things.

If you’re serious about migrating Microsoft 365 tenants at scale, app-only authentication isn’t an optimization — it’s a prerequisite that is also used in CloudBik.

Microsoft 365 Tenant-to-Tenant Migration: What Actually Breaks at Scale (and How to Design for It)

Manoj Dwivedi — Wed, 31 Dec 2025 13:21:05 +0000

When people talk about Microsoft 365 tenant-to-tenant migration, it often sounds straightforward: authenticate to both tenants, copy data, validate, done.

In reality, once you move beyond a few test users, things break in ways that aren’t obvious from documentation.

After working on multiple tenant migrations involving Exchange Online, OneDrive, SharePoint, and Teams, I’ve learned that the real challenge isn’t copying data — it’s designing a system that survives scale, throttling, and long-running execution.

This post isn’t a product pitch or a checklist. It’s a practical look at what actually causes pain in tenant migrations and how to design around it.

Tenant Migration Is Not a One-Time Copy Job

The biggest mistake teams make is treating tenant migration like a batch job.

It’s not.

Tenant-to-tenant migration behaves more like cloud data replication:

You have two isolated systems
Changes continue to happen during migration
APIs impose strict limits
Failures are guaranteed over time

Once you accept that model, many design decisions become clearer.

Delegated Auth Fails Sooner Than You Think

Delegated authentication feels convenient at first, especially for proof-of-concept migrations. But it breaks down quickly in production.

Common issues:

Token expiration mid-job
User-based throttling
Background jobs failing when sessions expire

For anything beyond a pilot, application-based authentication is mandatory. It gives you predictable behavior, stable permissions, and far fewer surprises during long-running operations.

Throttling Is Not an Error Condition

Microsoft Graph throttling (429, 503) is not a bug. It’s the platform telling you to slow down.

What causes trouble is when migration logic treats throttling as a failure instead of a signal.

At scale, these patterns work far better:

Respect Retry-After headers
Use exponential backoff
Limit concurrency per workload
Reduce batch sizes dynamically during peak hours

Unbounded parallelism might look fast initially, but it almost always collapses under sustained load.

Batching Helps — Until It Doesn’t

Graph batching (up to 20 requests per batch) is useful, but it’s not a silver bullet.

Batching works best when:

Requests are uniform
Payload sizes are small
Retry logic is granular

Problems appear when:

A single failed request blocks the whole batch
Payloads become too large
You retry entire batches instead of individual operations

In practice, the best systems mix small batches with fine-grained retry handling.

Migration Order Matters More Than Tools

Another common issue is migrating workloads in the wrong order.

A stable sequence looks like this:

Exchange Online
OneDrive
SharePoint
Microsoft Teams

Teams depends heavily on SharePoint and Microsoft 365 Groups. Migrating it early almost guarantees partial results and cleanup work later.

No tool can fix bad ordering.

Delta Sync Is What Saves Your Cutover

Full re-syncs don’t scale well.

Delta synchronization — based on timestamps or change tokens — is what makes:

Short cutovers possible
Rollbacks manageable
Re-runs safe

Without delta sync, every re-run feels risky. With it, migrations become iterative and predictable.

Observability Is Not Optional

If you can’t answer these questions, you’re flying blind:

Which users are lagging?
Which workload is throttled?
How many retries are happening per hour?
Where did failures start?

Good migration systems log:

Request IDs
Batch IDs
Retry counts
Last successful timestamps

This isn’t about dashboards — it’s about knowing where to slow down or pause before things spiral.

What I’d Tell Anyone Planning a Tenant Migration

If you’re planning a Microsoft 365 tenant-to-tenant migration, keep this in mind:

Design for failure, not success
Assume throttling will happen
Treat migration as replication, not copy
Prioritize observability early
Respect workload dependencies

When you do that, migrations stop feeling chaotic and start feeling controlled.

Final Thoughts

Microsoft Tenant-to-tenant migration is one of those problems that looks easy until it isn’t.

The teams that succeed aren’t the ones with the fastest scripts — they’re the ones that design with constraints in mind and accept that scale changes everything.

If you approach migration as a distributed systems problem, Microsoft Graph becomes far more predictable — and migrations become far less stressful.