Why the migration is the real switching cost — and still usually worth paying
The standard incumbent argument against switching alumni platforms is the migration itself: data export, re-permissioning, integration rebuild, member re-onboarding. Every item is true, and every item is a one-time cost. What the incumbent's pitch leaves out is the recurring cost of staying — a frozen roadmap, integrations that drift, an AI layer that exists as a slide rather than a shipped feature. Recent documented migrations by top-tier professional-services firms, off named legacy vendors and onto a single leading enterprise alumni platform, suggest those buyers ran the arithmetic and found the one-time cost smaller than the continuing one. But that arithmetic only holds if the migration is scoped honestly, and honest scoping means pricing the phases that never appear in a vendor's statement of work.
Phase 0: the export negotiation (won or lost before signature)
The migration begins while you are still a customer of the outgoing vendor — which is the only moment your leverage exists. The export you should have secured in the original contract is a complete, documented, machine-readable extract: alumni records with effective-dated history, engagement logs, event attendance, chapter memberships, media attachments, and configuration metadata. What vendors actually hand over without contractual pressure is a reduced "active members" CSV with no history and a services invoice attached.
If you are mid-contract with the incumbent, negotiate the export specification now, in writing, naming every data class and the format of each. If you are evaluating a new platform, the same clause belongs in the incoming contract — because the platform you buy this cycle may be the incumbent you exit next cycle. Budget nothing for this phase and you will pay for it later at rates you do not control.
Phase 1: data profiling and record linkage (2–6 weeks)
Before anything imports, someone must discover what you actually have. Alumni data typically arrives from several vintages: the current HRIS extract, legacy HR systems that predate it, the old platform's export, CRM fragments, and at least one spreadsheet maintained by a program owner who has since left. Profiling means counting duplicates, measuring field coverage per source, and identifying identity keys that still hold across systems.
Linkage — resolving "the same alum" across sources — is the phase that decides whether the new platform holds a graph or a graveyard. Deterministic matching on stable employee identifiers handles the easy majority; probabilistic matching on name and tenure handles most of the rest; the ambiguous middle needs a human review queue, and that queue is a labour line nobody budgets. Timelines here depend on base hygiene, not vendor speed: a clean 50,000-record base links in two weeks, a fifteen-year-old multi-source base can take six.
Phase 2: re-permissioning and lawful basis (4–8 weeks, calendar-bound)
Under GDPR-class regimes, the imported base is not yours to use simply because you exported it. A material share of records will predate the current privacy notice, the current platform, and sometimes the program owner's tenure. The defensible sequence: determine lawful basis per cohort with counsel in writing; run a re-permissioning campaign to the stale cohort with a clear explanation of what the new platform does and how to object; suppress promptly and prove the suppression holds.
This phase is calendar-bound rather than effort-bound — campaigns need notice periods, objection windows, and a second pass for non-openers. Compress it and you import your legal risk into the new system on day one, which is an expensive way to discover that the migration vendor's compliance tooling is a FAQ page.
Phase 3: integration rebuild (2–8 weeks, parallel)
HRIS sync, CRM, SSO, and marketing automation rebuilds run in parallel with the data phases, and their cost depends on one distinction vendors are slippery about: which connectors are native products the vendor maintains, and which are services projects built for you and inherited by you. Native connectors survive the vendor's own releases; services-built integrations are yours to babysit forever. Ask for the change-rate card — what you pay when an upstream API changes — and for whose problem a broken connector is under the support agreement.
Phase 4: configuration, content, and chapters (2–4 weeks, parallel)
Directory taxonomy, chapter structures, event categories, email templates, moderation policies, and the reporting pack leadership expects. The work is unglamorous and program-specific; the failure mode is importing the old program's configuration unchanged and paying migration prices for the status quo. Use the rebuild to fix the taxonomy you have been apologising for since the last platform.
Phase 5: member re-onboarding — the phase that kills migrations
Alumni will not read your migration announcement. Expect first-wave activation in single-digit percentages of the base, with the engaged minority arriving quickly and the long tail arriving only through repeated, valuable contact. The realistic plan is a sequenced comms programme — engaged segments first, chapter leaders as the second wave, dormant cohorts last with the re-permissioning notice folded in — plus a content calendar that gives the first ninety days a reason to be opened.
Set the internal success metric as engaged growth over twelve months, not launch-week registrations. A migration judged on day-one numbers will be declared a failure while it is still succeeding, and the organisation that declares it will not fund the comms that were always the point.
Phase 6: parallel run and legacy decommission
Decide before launch when the old platform turns off, and hold the date. Parallel runs drift from insurance into double-running: two systems of record, two licence bills, and alumni finding whichever one sends better emails. The standard pattern is a 60–90 day overlap, read-only legacy access thereafter, and decommission with a final export and deletion certification at the end.
The realistic shape
| Phase | Typical duration | Who does the work | What vendors quote it |
|---|---|---|---|
| 0 — Export negotiation | Contract-dependent | You, with counsel | Rarely (it is your cost to demand) |
| 1 — Profiling & linkage | 2–6 weeks | Shared; review queue is yours | Partly |
| 2 — Re-permissioning | 4–8 weeks | You (vendor tooling) | Rarely |
| 3 — Integrations | 2–8 weeks | Vendor + your IT | Build only, not change/drift |
| 4 — Configuration | 2–4 weeks | Program team | Partly |
| 5 — Re-onboarding | Ongoing, 90-day push | You (comms effort) | Almost never |
| 6 — Decommission | 60–90 days post-launch | You + outgoing vendor | Never |
The 80% rule
Vendors quote phases three and four, gesture at one and two, and omit zero, five, and six. When you model the true cost, the vendor's number is usually the minority of it — which does not make switching wrong; the documented migrations of firms with every reason to stay put say it is often right. It makes the honest model the difference between a migration that is funded and a migration that is discovered, halfway through, to be twice the price. Scope all seven phases, name an owner for each before signature, and put phase zero in the contract while someone still has to earn your business.