Migration Assistance¶
Operational support service — instantiates Change Resistance Diagnosis and Support
Hands-on help that physically moves data, tooling, and routines from the old world into the new — and keeps a way back — so the crossing is not left to each person to improvise.
Migration Assistance is the staffed, hands-on service that does the crossing for people — or alongside them — rather than merely encouraging them to cross. Its defining premise is that a great deal of resistance is not reluctance but labor: the new state is workable in principle, but getting there means moving data, rebuilding macros, re-linking integrations, re-creating templates, and re-learning where everything lives, and every hour of that migration is borrowed from someone's real job. So this mechanism supplies the hands — a migration team, tooling, and a runbook — that carry the freight of the transition, and it explicitly holds open a way back: a parallel-run period and a documented revert path so that if the crossing goes wrong, work does not stop. It reduces the practical burden of moving, and it does so by acting on the artifacts and the safety net, not on people's skills or beliefs.
Example¶
A mid-size accounting firm is moving fifty preparers off a legacy on-premises tax package onto a cloud platform two months before filing season — the worst possible time to lose a day. Left to self-serve, each preparer would have to export client files, rebuild depreciation schedules, and re-key organizer templates, and most would simply keep using the old software until the deadline forced a chaotic scramble. Migration Assistance instead sends a small team that bulk-migrates client files, scripts the conversion of the firm's shared macros, and rebuilds the standard organizer templates centrally, so a preparer arrives Monday to find their client roster already in the new system. Critically, it keeps the legacy package fully licensed and read-only through the entire season — a documented fallback: if a converted return doesn't tie out, the preparer reverts to the old file for that client while the migration team fixes the conversion, and no return is held hostage to a bad import. The resistance that would have shown up as "I'll switch after April" never forms, because the costliest, riskiest part of switching was carried for them and the escape hatch was real.
How it works¶
What distinguishes this mechanism from generic "support" is that it does the mechanical crossing:
- Move the freight centrally. Data, configurations, integrations, and templates are migrated in bulk by a dedicated team and tooling, not re-created by each end user, which is where the hidden cost and the errors otherwise live.
- Sequence around the real calendar. The crossing is timed and staged so it lands when the affected group can least afford disruption the least — before a peak, not during it.
- Hold a documented way back. A parallel-run window and an explicit revert rule keep the old state available and usable until the new one is proven, so a failed conversion is an inconvenience rather than a stoppage.
- Hand off clean. Migrated artifacts are verified against the source before the old state is retired, so people are not silently handed corrupted data.
Tuning parameters¶
- Service intensity — full white-glove migration versus guided self-service with a helpdesk. White-glove removes the burden entirely but is expensive and can leave users ignorant of the new system's internals.
- Parallel-run duration — how long the old state stays live as a fallback. A longer window de-risks the crossing but delays the point where the new routine becomes the only routine.
- Batch vs. wave — migrating everyone at once versus in cohorts. Batch is fast and clean; waves contain blast radius and let the team learn between cohorts.
- Verification depth — spot-checking versus full reconciliation of migrated artifacts. Deeper verification catches silent corruption but slows the crossing and costs labor.
- Revert threshold — how broken a conversion must be before falling back. A loose threshold reverts at any friction and never lets the new state stick; a tight one strands people on a half-working import.
When it helps, and when it misleads¶
Its strength is that it dissolves the switching-cost form of resistance — the entirely rational refusal to eat a large, risky, one-time labor cost with a deadline looming — and the parallel-run fallback removes the fear that crossing means losing a safe way to keep working.
Its failure mode is the "lift and shift" trap: the migration faithfully moves the old world's dysfunction into the new system — the same messy folder structure, the same broken macros — so nothing improves and users conclude the change was pointless.[n1] A subtler misuse is an over-generous parallel run that becomes permanent: the old state never gets turned off, people keep one foot in it, and the migration never actually completes. The discipline that guards against both is to migrate deliberately — cleaning and re-structuring during the crossing rather than photocopying the mess — and to set a firm sunset on the fallback so the way back is a safety net, not a permanent hedge.
How it implements the components¶
transition_support— this mechanism is the coordinated, hands-on assistance (staffing, tooling, data movement, template rebuild) that makes the mechanical move feasible rather than merely encouraged.fallback_rule— the parallel-run window and documented revert path are an explicit fallback: a stated rule for when and how to return to the legacy state so a failed crossing never halts the work.
It moves the artifacts, not the person: building the skill and confidence to *use the new system is Training and Practice Program's job, a different facet of support entirely. And it does not track whether adoption then sticks — adoption_monitoring and relapse_and_workaround_signal belong to Adoption Dashboard.*
Related¶
- Instantiates: Change Resistance Diagnosis and Support — the response matched to a diagnosed switching-cost barrier, carrying the freight of the crossing.
- Consumes: Barrier Interview Protocol supplies the diagnosis that the barrier is switching cost rather than skill, trust, or incentive.
- Sibling mechanisms: Adoption Dashboard · Barrier Interview Protocol · Incentive Realignment · Pilot Rollout · Training and Practice Program · Trust-Building Communication · Participatory Design Session · Transition Support Plan · Change Readiness Assessment
Editorial Notes¶
Form Classification¶
Form family: Intervention, Treatment & Transformation
Rationale: The mechanism directly moves data, configurations, integrations, and routines into the new environment while maintaining a reversible crossing.
Nearest alternative: Organization, Role & Governance — A dedicated team may provide the service, but the operative form is the hands-on transformation of the target system and work practices.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Hands-on transition support and reversible changeover belong to organizational change management.
Related originating lineages:
- Computer Science & Software Engineering — Data, tooling, and compatibility migration provide the concrete operational setting.
Review outcome: Independent reviewer agreement; medium confidence.
Notes¶
[n1] Lift and shift — a migration that relocates a system's contents into a new environment without redesign. Convenient and fast, it faithfully carries the old world's dysfunction across, which is why a migration meant to reduce resistance must clean and re-structure during the crossing, not merely copy. ↩