Migrate what matters

How I challenged feature-parity migration, secured approval for a narrower scope and avoided approximately two months of projected development effort.

Context

Which parts of the legacy task experience still deserved to exist after migration?

The initial brief assumed feature parity: both an All Tasks view and a Filtered View were scheduled for development. Engineering and the BA had already estimated the work. The All Tasks scope alone represented approximately two months of projected development.

The acquired product was moving onto a new platform in stages, with the new system temporarily operating inside the old one. That transition made it important to preserve necessary workflows, but it also created an opportunity to question features whose purpose had changed.

In the anonymized example shown here, tasks are represented as configuration changes. “All changes” represents All Tasks, while “Platform-level changes” represents the filtered experience.

Role: Product Designer
Status: Shipped
Evidence: Product observation and discovery with experienced user representatives
Approval: BA and client stakeholder
Outcome: Approximately two months of projected development effort avoided

Problem

When the requirement reached design, I questioned whether rebuilding All Tasks was justified. Most relevant activity was already handled inside contextual workflows. A second generic surface risked duplicating functionality users no longer needed.

Checkout API service page with Production selected and a Configuration changes table showing status, requester and last update. — Service-specific changes were already available within the service and environment. This was the contextual workflow the migration needed to preserve.

Core changes were already available within the relevant service and environment. The possible gap was access to changes outside that context, such as shared infrastructure or organization-wide policies.

Responsibility

Across the broader migration project, I support four teams and champion design-system alignment so patterns, components and interaction conventions remain consistent.

As Product Designer, I worked with the BA and experienced user representatives to re-evaluate the migration requirement. My recommendation needed to preserve necessary access while reducing unnecessary scope.

The initial pushback was a hypothesis, not a conclusion. Rather than remove the requirement based on assumption, I used discovery to test whether any important use case would be lost.

Discovery

Observation of the existing product and discovery with experienced user representatives showed that All Tasks was rarely needed. When people did use it, they were locating non-core tasks through filters. Core work was already handled contextually elsewhere.

In this public example, users opened “All changes” and applied the “Platform-level” filter. They needed access to those remaining changes, rather than a complete overview of changes across every service.

Platform-level changes table listing shared infrastructure and policy changes, with IDs, affected resources, environments and statuses. — The remaining gap: changes to shared infrastructure and organization-wide policies. Shown here as a focused view, these were the records engineers were looking for in the old system.

The finding changed the migration question: we needed to preserve the filtered use case, not rebuild the generic page that happened to contain it.

Decisions

I recommended dropping All Tasks and retaining only the filtered workflow for the remaining use case.

This removed a duplicate route for core work, preserved access to non-core tasks and narrowed the build and future maintenance scope. The trade-off was deliberate: users would no longer have one all-purpose page, and core actions would remain in their contextual workflows.

I worked with the BA and experienced user representatives on that recommendation. The BA and client stakeholder approved the revised requirement, and the narrower solution shipped.

Comparison of migrating a specific view versus the full change list, headed Migrate based on need, not based on legacy feature. — The narrower scope preserves the remaining use case. Avoided development effort was based on an estimate; lower maintenance needs and reduced error risk were expected benefits.

Outcome

Approximately two months of projected development effort avoided. Engineering and the BA had estimated the removed All Tasks scope before implementation. Eliminating it avoided that projected effort while preserving the remaining use case through filtering.

The solution was also designed to reduce error risk. Generic task pages allowed actions without enough contextual guidance; contextual workflows pre-filled or constrained relevant information. Keeping core actions there reduced the need to enter relationships and task details manually. This was an expected benefit, not a measured reduction in post-launch errors.

Reflection

The project reinforced that migration should not default to feature parity. Discovery changed what the team decided to build, not just how the migrated interface looked.

Removing an obsolete surface was more valuable than redesigning it well.