Moving a complex workflow to a new platform
A generalized practice study of using discovery to choose the right migration response, then defining failure boundaries by what people can safely and truthfully continue doing.
- Use-case discovery
- Evidence-led scope
- Task continuity
Evidence boundaryThis study groups transferable decision patterns. It does not document one employer project or reproduce an internal workflow. The representative decisions and intended effects are not claims of implementation or measured results.
Context
A migration request is a starting point for discovery, not a specification to recreate.
This study uses two representative assumptions: a capability appears in a migration plan because an equivalent feature exists in the legacy platform; a target-platform task depends on information and actions that can become unavailable independently. No organization, product, team, timeline, or observed outcome is depicted.
These assumptions create two related risks: selecting a legacy interaction before establishing the current need, and allowing technical boundaries to dictate how much of the experience fails. The decision patterns below are not a project chronology.
Design responsibility
My proposed responsibility is to make the decision and its evidence gap explicit.
I would frame the problem, compare alternatives, propose the smallest justified scope, translate dependency consequences into interface behavior, and define what must be validated. The accountable product owner retains the scope decision. Domain owners confirm user needs and consequences; technical owners confirm feasibility and independent recovery.
A design recommendation, accountable approval, implementation, verification, and an observed outcome are distinct. This study demonstrates the first and specifies what the others would require.
Migration scope
Discover the use cases before selecting the migration solution.
An implementation-shaped request does not establish the task, frequency, consequence, or gap in the target platform. I would first ask:
Which current use cases require support, and which interaction pattern fits them in the target platform?
Discovery-to-solution trace
From migration request to justified response
- 1Migration request
Record what is being requested.
- 2Use-case discovery
Understand tasks and consequences.
- 3Capability audit
Check what the target already supports.
- 4Residual problem
Name the gap that remains.
- 5Solution decision
Select the response supported by evidence.
MIG-01 · Representative graphic
Proposed direction
Discovery is required regardless of the eventual solution. If the target platform supports the validated use cases and no meaningful residual problem remains, I would recommend adding no capability. Carrying the original interaction forward remains valid when it is the strongest fit. A valid need with an unsuitable interaction calls for rework.
Legacy behavior need not be declared wrong. Its existence is simply insufficient evidence for choosing a solution.
Intended effect and reopen criteria
The intended effect is to prevent overlapping functionality and reserve product capacity for evidenced user problems. No saved work, time, or money is claimed.
I would reopen an add-nothing recommendation if new evidence reveals:
- A recurring task the existing capability cannot complete.
- A material accessibility, permission, or discoverability barrier.
- A consequential edge case whose frequency and cost justify investment.
- A technical limitation that makes apparent overlap unreliable.
- A changed workflow or policy that creates a residual need.
Dependency states
Degrade only the affected capability, unless continuing would invalidate the task.
A page-level failure can hide usable work; treating every failure as harmless can conceal information required for a valid decision. I would ask:
What is the smallest truthful failure boundary, and when would continuing make the task invalid or unsafe?
Keep valid work available during migration
When a dependency fails, what can the person still do?
Supplemental reference unavailable
Your draft is still available.
Retry referenceRequired decision input unavailable
Restore the required input before proceeding.
Retry required inputMIG-03 · Representative graphic
- Core task record
- Consequence The task cannot be identified or acted on truthfully.
- Boundary and recovery Block the task. Explain what is unavailable; restore the required record before continuing.
- Authorization or eligibility
- Consequence Permission for a consequential action cannot be established.
- Boundary and recovery Block the affected action. Preserve safe inspection where possible; establish permission before enabling the action.
- Required decision input
- Consequence A valid decision cannot be made without the missing information.
- Boundary and recovery Prevent progression at the decision point. Explain which input must become available.
- Supplemental reference
- Consequence Context is reduced, but the primary task remains valid.
- Boundary and recovery Preserve available work. Identify the unavailable region and offer independent retry where supported.
- Historical or advisory context
- Consequence Confidence may be reduced, but no required rule depends on this information.
- Boundary and recovery Preserve the task, identify the missing context, and offer retry where useful.
These are representative categories and proposed recovery treatments, not an implemented policy or a real architecture. Domain review must establish criticality; technical review must establish which regions can recover independently.
State names must tell the truth
- Loading
- Information is being retrieved within its expected interval.
- Empty
- Retrieval succeeded and no relevant information exists.
- Unavailable
- Retrieval or processing failed for the identified region or capability.
- Restricted
- The person is not permitted to access or perform something.
- Conflict
- Valid domain information prevents the requested action.
- Processing
- Work is continuing asynchronously and has not failed.
An empty result is not a failed retrieval; an unknown permission is not a confirmed restriction. State names should describe what the system knows. Retry is a recovery action, not a substitute for explaining the condition.
Proposed direction and intended effect
Classify each dependency by the consequence of absence. Block only when continuing would be invalid, unauthorized, or unsafe. Otherwise preserve unaffected work and localize the unavailable state.
The intended effect is task continuity during partial failure without concealing consequential uncertainty. This is a design aim, not an observed result.
Validation
The framework is inspectable; its application would still need evidence.
- Map each visible decision and action to the information and permissions it requires.
- Review criticality with domain and accountable product owners; do not infer it from technical architecture alone.
- Walk through loading, empty, unavailable, restricted, conflict, retry, and recovery with representative users. Include asynchronous processing so ongoing work is not mistaken for failure.
- Confirm with technical owners which regions can resolve and retry independently.
- Verify consequential behavior through observable evidence before treating implementation as complete: required inputs prevent invalid progression, localized failures preserve valid work, and recovery restores only the affected capability.
- Revisit scope and criticality when workflow, policy, frequency, or dependency behavior changes.
The migration decision also needs evidence that people can discover and complete the validated tasks with the selected interaction. A recommendation should remain open to contrary evidence rather than treating the decision record as proof of success.
Validating the migration response
Every response has a burden of proof.
MIG-02 · Representative graphic
- Carry forward
- Evidence required Discovery validates the use cases, the original interaction supports them without a material usability problem, and it fits the target platform.
- Reopen or redirect when Familiarity is the only argument, the interaction conflicts with the target model, or it carries forward a known problem.
- Reuse
- Evidence required A target-platform capability already supports the validated use cases without a material gap.
- Reopen or redirect when People cannot discover or complete a required use case.
- Adapt
- Evidence required An existing pattern covers the core need and the remaining gap is bounded and evidenced.
- Reopen or redirect when Adaptation would create overlapping behavior or distort the pattern’s meaning.
- Rework
- Evidence required The need is valid, but neither the legacy interaction nor a target-platform pattern fits sufficiently.
- Reopen or redirect when The problem, audience, or consequence remains unverified.
- Add nothing
- Evidence required Discovery establishes no residual use case requiring product change.
- Reopen when New evidence demonstrates a meaningful gap.
Reflection
The value of the method is choosing what deserves to change and what can remain usable.
This study makes my proposed criteria, alternatives, and validation responsibilities visible. It demonstrates product judgment through a migration-scope framework and a dependency-state model. It does not establish that either recommendation was approved, implemented, or successful in a particular workplace.
The examples and text models are independently authored. They group transferable decision patterns without reproducing employer artifacts, internal workflows, actual technical details, or a single project history. The representative graphics and supporting text illustrate the method; they are not employer artifacts.