An architect is asked how long a migration will take and has genuinely no basis for a number. How should estimation be approached so the answer is useful rather than either false precision or a refusal?

Why the request is legitimate

"I cannot estimate that" is usually true and is rarely an acceptable answer, because someone must make a resource decision and will do so with or without your input. An absent estimate is replaced by a worse one from someone with less information.

The productive move is not to refuse but to make the uncertainty part of the answer.

Ranges, not points

"Between four and nine months" conveys more information than "six months", and it conveys it honestly. A point estimate is interpreted as a commitment and its uncertainty is discarded by the second person who repeats it.

Give the range with the reasoning for its width: "four months if the legacy data is as clean as the sample suggests, nine if the undocumented consumers we have found so far are representative of what remains."

Decompose, because the aggregate is not estimable

A large migration cannot be estimated as a whole and its parts frequently can. Decompose until the pieces are comparable to work the team has done, and identify the pieces with the widest uncertainty — because those dominate the total and are where investigation pays.

The decomposition itself is the deliverable. It shows what the work consists of and where the risk sits, which is more useful to a decision-maker than any single number.

Reduce the uncertainty rather than estimating it

The most valuable response to "we don't know" is frequently "give us two weeks and we will know."

• A spike on the riskiest component, timeboxed.
• A count of the actual scope — how many consumers, how many tables, how many endpoints — which is often unknown and cheaply discoverable.
• Migrating one small thing end to end, which converts every subsequent estimate from speculation into multiplication. This is the single highest-value estimation technique for migrations and is skipped because it feels like starting without a plan.

What to include that people forget

• Coordination with other teams, which frequently dominates elapsed time.
• The long tail — the last 10% of consumers who are unresponsive, unowned or on an old version.
• Decommissioning, which is real work and is where migrations stall.
• Reconciliation and verification, especially where data correctness must be proven.
• The team's other commitments, since capacity is not headcount.

How to communicate it

State the range, the assumptions, the biggest uncertainty and what would narrow it. Then offer a decision point: "we will know much more after the first component; let us reforecast then."

Re-forecast as evidence arrives, publicly. An architect who revises an estimate with reasoning is more credible over time than one who defends the original — and the revision is legitimate precisely because the uncertainty was stated at the outset.