Asana Did Not Let 150 Migrations Learn the Same Mistake

A large migration is dangerous not only because any individual change can be wrong. It is dangerous because one wrong assumption can be copied into dozens of changes before anyone has enough evidence to challenge it.

Asana faced that exposure when moving 66 Admin Console settings through roughly 150 migrations across several shared frameworks. Its answer, described in a first-party engineering report published on September 16, 2026, was not to freeze a larger upfront brief and run every migration at once. The team split the work into tickets, ran independent tickets in parallel batches, reviewed each wave, and revised the tickets that remained.

That is the important process lesson for a platform team. Parallelism should increase throughput after a direction is credible. It should not multiply an untested direction.

The exposure was repetition, not one difficult change

Long-running engineering work has a familiar failure mode. A short prompt or a temporary working session loses the original problem, prior decisions and acceptance criteria. A detailed specification appears to solve that loss of context. But it introduces a different risk: it can preserve a mistaken assumption so consistently that code, tests and follow-on work all reinforce the wrong direction.

For a migration programme, that risk compounds. If a team treats 150 similar changes as one fully settled brief, an early misunderstanding may become 150 well-documented instances of the same defect. Rework then means reconstructing the decision, finding every affected ticket and correcting work that has already moved through review.

Asana’s documented workflow kept a durable chain from Problem to Research, Spec, Review, Implementation and Verification. The point was not merely to generate implementation work faster. It was to retain the reasoning needed for a later engineer or session to understand what was being changed, why it was being changed and what would count as complete.

Turn a repeated migration into a sequence that can learn

1. State the problem before proposing a change. Record the business or platform condition that requires migration, rather than only the intended implementation.
2. Research the affected area and write a specification that retains key decisions and acceptance criteria across later implementation sessions.
3. Before implementation, play back the proposed understanding and surface questions that could materially change the plan. An engineer can correct direction here, before code must be rewritten.
4. Create one bounded ticket per migration. In Asana’s case, tickets could carry the operational context and provide a unit of assignment, review and history.
5. Run independent tickets in parallel batches rather than as one irreversible release of the entire population.
6. Review each completed wave, then update the remaining tickets from what the team learned before they run. Verification closes the individual migration; the review wave improves the unfinished programme.

This structure separates two useful kinds of scale. A team can execute independent work concurrently. At the same time, it can retain a deliberate learning interval between batches. The interval is not administrative drag. It is the point at which evidence from real implementation can still change future work cheaply.

The reported result is useful, but narrow

Asana reports that 91% of migrations in this approximately 150-migration effort required no revision after review. That is not an accuracy rate for specifications, coding tools or migrations generally. It is the company’s reported share of migration units in this defined effort that did not need revision after review; the report does not publish the exact numerator behind the rounded percentage.

The team also reports shipping more than one month earlier than its original plan. This is a reported outcome from Asana’s own case, not a general forecast for similar programmes. The source does not disclose the original schedule, actual delivery dates or a controlled counterfactual. It would therefore be wrong to attribute the whole schedule change to review waves or to promise the same result elsewhere.

The case is still operationally valuable without that leap. It supplies a concrete population, a visible intervention and a bounded outcome: early review informed work that had not yet run. For a platform owner, that is a more actionable claim than a broad productivity statistic. Asana also published a separate analysis of seven engineers and 524 merged pull requests over four months, but describes that comparison as uncontrolled. It is not needed to understand this migration design.

Human judgment did not leave the process

The workflow did not remove engineers from the decision path. Engineers reviewed the plan, corrected consequential assumptions, reviewed migrations and judged architectural implications. Automation carried retained context, supported bounded implementation work and could run checks. The human role was to decide whether the problem had been understood correctly and whether the available evidence justified continuing.

• Automate the preservation of context and the preparation of bounded migration work.
• Keep architectural judgment, material trade-offs and evidence sufficiency with engineers.
• Use the batch review to challenge the direction, not only to check whether a ticket was completed.
• Update unfinished work when the evidence changes; do not protect an old specification merely because it is detailed.

A good specification can still preserve a bad premise

Asana explicitly identifies the boundary that matters most. A detailed specification can make a wrong assumption easier to carry through implementation and tests. For riskier decisions, an independent human must return to the original goal and challenge the direction of the work.

That warning sets the limit of the pattern. Review waves are not a substitute for understanding dependencies, defining what is safe to run in parallel or deciding when a migration affects a consequential architectural choice. They are a way to stop repeated work from becoming repeated error when the work can be divided into bounded units.

“Scale the work only after the team has created a place for early evidence to change the work that remains.

The practical rule for platform teams

When a repeated migration is large enough to justify parallel execution, design two things at once: the ticket boundary and the learning boundary. Each ticket needs enough context to be implemented and reviewed. Each batch needs a review point early enough to revise the rest of the queue.

Start with the migration family that has repeated structure but meaningful uncertainty. Define the problem, decisions and acceptance criteria; ask the questions that could change the plan; run a first bounded wave; and make revision of remaining tickets an expected part of the process. If you are planning a similar platform change, discuss the batch boundary before choosing how many workers or tools to add.

Source and scope: Asana, “Spec-driven development,” September 16, 2026, a first-party report describing three months of internal use. The relevant population was 66 Admin Console settings and roughly 150 migrations across shared frameworks. Asana’s current ticket documentation supports the availability of ticket descriptions, ownership, attachments, dependencies and review history, but does not independently validate the reported case outcomes. Sources: https://asana.com/inside-asana/spec-driven-development and https://help.asana.com/s/article/creating-and-managing-tickets-in-command