By hand, scripts, consultancy or TenantFlex

	By hand	In-house scripts	Consultancy	TenantFlexread-only source
Elapsed time for 100 applications	Months. Each application waits on an engineer's calendar and then on its owner.	Weeks to write and debug the scripts, then weeks to run them. Faster the second time, if there is one.	Weeks to months, driven by the statement of work and the consultants' availability.	Days of platform work. Elapsed time is set by owner cutover scheduling, not by the recreation.
Engineer effort per application	Two to four hours: export, rebuild settings, rewrite claims, upload certificate, recreate assignments, test, write up.	Minutes per app once the scripts work, plus the hours spent on every edge case the scripts did not anticipate.	Billed per application or per day. The effort is the same as by hand, performed by someone else.	Minutes of review per application. Discovery flags the ones that need a decision; the rest run in a job.
Claims and attribute mappings	Rewritten by hand in the destination's syntax. The most common source of day-one sign-in failures.	Whatever the script author covered. Expressions and transformations are usually left for later.	Rewritten by hand by the consultant, against a spreadsheet of mappings.	Mapped through one vocabulary and written in the destination's form. Complex claims are flagged before anything moves.
Verification	Someone clicks through each application, if there is time.	Rarely. Scripts write; they seldom read back and compare.	Usually a test sign-in per application, recorded in a tracker.	Every setting is read back from the destination and compared with the source. The result is in the execution log.
Rollback	Manual deletion in the destination, from memory of what was created.	Depends on whether a rollback script was written and tested.	Manual, by the consultant, under the same pressure as the migration.	Job-wide. If an application fails mid-run, what the job created is removed and the source is unchanged.
Evidence for audit	Tickets and screenshots, assembled afterwards.	Script logs, if kept.	The consultant's close-out report.	An execution log per job, an audit trail per action, and an export of both as CSV or JSON.
Owner hand-off	An email per application with the new metadata, written by hand.	Usually a generated spreadsheet.	A runbook or email per application.	A hand-off bundle per application: the destination settings, certificate, log and notes the owner needs to repoint.
Risk to the source tenant	Low, but the engineer is signed in as an administrator on both sides for weeks.	Depends on the credentials the scripts run with. Often read-write on both tenants.	Consultants need administrator access to both tenants for the engagement.	The source connection is read-only by permission. Write access exists only on the destination.
Repeatable for standby or fail-back	No. The work is done once and the knowledge leaves with the engineer.	Partly, if the scripts are maintained as the providers' APIs change.	No. A second engagement is a second statement of work.	Yes. The same job runs again to pick up new applications, and in reverse for fail-back.
Cost model	Internal time, usually not counted, plus the cost of the delay.	Internal time to write and maintain, plus the risk of the scripts' author leaving.	Day rate or per-application fee, plus internal time to manage the engagement.	Licensed per application in scope. Discovery gives the number before you commit. White-glove available.
Best for	A handful of applications and no deadline.	Teams with API experience and a migration they will repeat.	Organisations that want the whole programme run for them.	Any migration with a date on it, a standby that must be rehearsed, or a renewal that needs a credible alternative.

By hand

In-house scripts

Consultancy

TenantFlexread-only source

Elapsed time for 100 applications

Months. Each application waits on an engineer's calendar and then on its owner.

Weeks to write and debug the scripts, then weeks to run them. Faster the second time, if there is one.

Weeks to months, driven by the statement of work and the consultants' availability.

Days of platform work. Elapsed time is set by owner cutover scheduling, not by the recreation.

Engineer effort per application

Two to four hours: export, rebuild settings, rewrite claims, upload certificate, recreate assignments, test, write up.

Minutes per app once the scripts work, plus the hours spent on every edge case the scripts did not anticipate.

Billed per application or per day. The effort is the same as by hand, performed by someone else.

Minutes of review per application. Discovery flags the ones that need a decision; the rest run in a job.

Claims and attribute mappings

Rewritten by hand in the destination's syntax. The most common source of day-one sign-in failures.

Whatever the script author covered. Expressions and transformations are usually left for later.

Rewritten by hand by the consultant, against a spreadsheet of mappings.

Mapped through one vocabulary and written in the destination's form. Complex claims are flagged before anything moves.

Verification

Someone clicks through each application, if there is time.

Rarely. Scripts write; they seldom read back and compare.

Usually a test sign-in per application, recorded in a tracker.

Every setting is read back from the destination and compared with the source. The result is in the execution log.

Rollback

Manual deletion in the destination, from memory of what was created.

Depends on whether a rollback script was written and tested.

Manual, by the consultant, under the same pressure as the migration.

Job-wide. If an application fails mid-run, what the job created is removed and the source is unchanged.

Evidence for audit

Tickets and screenshots, assembled afterwards.

Script logs, if kept.

The consultant's close-out report.

An execution log per job, an audit trail per action, and an export of both as CSV or JSON.

Owner hand-off

An email per application with the new metadata, written by hand.

Usually a generated spreadsheet.

A runbook or email per application.

A hand-off bundle per application: the destination settings, certificate, log and notes the owner needs to repoint.

Risk to the source tenant

Low, but the engineer is signed in as an administrator on both sides for weeks.

Depends on the credentials the scripts run with. Often read-write on both tenants.

Consultants need administrator access to both tenants for the engagement.

The source connection is read-only by permission. Write access exists only on the destination.

Repeatable for standby or fail-back

No. The work is done once and the knowledge leaves with the engineer.

Partly, if the scripts are maintained as the providers' APIs change.

No. A second engagement is a second statement of work.

Yes. The same job runs again to pick up new applications, and in reverse for fail-back.

Cost model

Internal time, usually not counted, plus the cost of the delay.

Internal time to write and maintain, plus the risk of the scripts' author leaving.

Day rate or per-application fee, plus internal time to manage the engagement.

Licensed per application in scope. Discovery gives the number before you commit. White-glove available.

Best for

A handful of applications and no deadline.

Teams with API experience and a migration they will repeat.

Organisations that want the whole programme run for them.

Any migration with a date on it, a standby that must be rehearsed, or a renewal that needs a credible alternative.

When not to use TenantFlex

If you have fewer than ten applications and no end date, do them by hand; the platform will not pay for itself.

How we counted

Hours per application by hand come from the migrations the founders ran before building TenantFlex, and match what customers report in discovery calls. Elapsed time assumes the usual constraint: application owners can test and repoint only in their own change windows. Your numbers will differ; the calculator lets you put in your own.

Compare it on your own tenant.

Discovery is read-only and takes an afternoon. You get the application count, the bands and the credential expiry list whichever approach you choose.