Reference card — paid community operations
Paid community platform migration
How paid community operators evaluate, plan, and execute a platform migration — and how to protect member activation and retention through the transition: a migration decision table covering seven trigger signals with stay vs. migrate thresholds; a platform capability comparison across six platforms (Slack, Circle, Discord, Mighty Networks, Kajabi, Skool) and eight dimensions including onboarding support, Day 0 DM effectiveness, analytics depth, and per-member cost at scale; a pre-migration checklist covering member data, content, integrations, and onboarding sequence rebuild; a member communication timeline from six weeks pre-cutover through day-30 post-migration; an activation impact table by onboarding structure type (high-touch, semi-managed, self-serve); six common migration failure modes with prevention and recovery guidance; and post-migration health metrics to track for 90 days. Companion to the member onboarding reference card (which covers Day 0 DM anatomy and activation event decision table) and the churn prevention reference card (which covers the full intervention playbook for at-risk members).
TL;DR
Platform migrations are the highest-churn event in the lifecycle of a paid community — operators who execute without a structured communication timeline and a complete onboarding rebuild on the new platform lose 30–55% of members in the first 90 days post-migration. The three levers that predict migration success are: six-week member communication timeline (vs. two-week = 30–45% lower completion rate), onboarding sequence rebuilt and tested before cutover day (not after), and personal operator outreach to non-migrated members at day 7 and day 30. The platform that is right for your community is not the one with the most features — it is the one where your specific activation mechanic (DM-first, content-first, or event-first) is natively supported without requiring a third-party build. Table 1 gives the migration decision table. Table 2 gives the platform capability comparison. Table 3 gives the pre-migration checklist. Table 4 gives the member communication timeline. Table 5 gives the activation impact by onboarding structure type. Table 6 gives migration failure modes. Table 7 gives post-migration health metrics.
Why platform migrations are different from product launches
A new product launch delivers something that did not exist before. A platform migration delivers the same community through a different interface to members who already have a behavioral relationship with the old interface. The difference matters because member retention during a migration is not driven by the new platform’s quality — it is driven by the operator’s ability to recreate the specific behaviors that made the old platform a habit. A member who posted in #wins every Friday in Slack because the channel existed and was reinforced by a weekly nudge will not automatically recreate that habit on Circle unless the equivalent space exists, is visible on first login, and is reinforced by the same nudge at the same cadence. The behavior did not transfer with the account data — it has to be rebuilt.
This is why migration retention data shows such a wide spread: operators who treat migration as a technical data export produce 44–58% member retention at 90 days; operators who treat migration as a full onboarding event for every existing member produce 82–91% retention at 90 days. The gap is not explained by the platforms involved or the community size — it is explained by whether the operator rebuilt the behavioral scaffolding (onboarding sequence, channel architecture, nudge cadence) on the new platform before announcing the migration to members.
The core migration insight: A platform migration is an onboarding event for every existing member, not just new ones. Every member on the new platform faces the same profile-completion and first-post challenge that a brand-new member faces — plus the friction of a tool they did not choose. The mitigation is to run the full new-member onboarding sequence for all migrating members, not just for post-migration new joins. See the member activation rate reference card for the activation benchmark table and the engagement benchmarks reference card for the behavioral signals to monitor.
Table 1: Migration decision table — when to migrate vs. when to stay
Seven trigger signals operators commonly cite when evaluating a platform migration, with the threshold at which the signal justifies migration cost (migration planning, member communication, data export, integration rebuild, and 30–60 days of reduced activation during transition), the signal level at which staying and optimizing is the correct decision, and the confounding factor that causes operators to misread the signal. The migration cost baseline for a community of 100–500 members is 40–80 hours of operator time and a 15–30% temporary activation drop during the 60-day transition window.
| Trigger signal | Migrate threshold | Stay & optimize threshold | Common confound |
|---|---|---|---|
| Monthly member churn rate | >5%/month for 3+ consecutive months AND root cause analysis identifies platform friction as a primary factor (member exit survey or direct conversation confirms platform UX as a reason, not just content or price) | Churn >5% but exit interviews cite content, price, or life change as primary reason. Platform friction is a secondary or absent complaint. Optimizing onboarding sequence on current platform is the correct lever — see the churn prevention reference card. | Operators attribute churn to platform when the real cause is a content or engagement gap. Run 5 direct exit interviews before treating churn as a platform signal — most churn at <5%/month is recoverable without migration. |
| Platform per-member cost exceeds 15% of ARPU | Per-member platform cost >15% of ARPU at current scale, with no lower-tier pricing available and no migration to a higher-ARPU tier achievable in the next quarter | Cost 10–14% of ARPU. Negotiate the annual pricing tier on current platform before migrating — most platforms offer 15–25% discounts for annual contracts that are not advertised publicly. | Operators calculate platform cost against gross revenue rather than ARPU per active member, which inflates the apparent cost burden. Calculate: (platform monthly cost) ÷ (active paying members) and compare to (average member monthly fee) to get the true percentage. |
| Integration gaps with external tools | Critical integration absent AND no API/Zapier workaround exists that does not require weekly manual intervention (e.g., payment processor cannot sync member access automatically; CRM cannot receive join/churn events; email list cannot stay in sync without manual export) | Integration gap exists but a Zapier or webhook workaround covers it with <30 minutes/week of manual intervention. Migrate when the workaround exceeds 30 minutes/week or creates error conditions that require member-facing recovery. | Operators migrate for integration gaps that a $49/month Zapier upgrade would solve. Audit the available integration surface on the current platform before scoping a migration — most gaps in Slack, Circle, and Discord are addressable without platform change. |
| Operator time on platform administration | >8 hours/week on platform-specific admin (moderation, member management, content organization, permission management) that is not justified by community value created and cannot be reduced by automation on the current platform | 6–8 hours/week on admin. Audit whether the time is platform-driven (e.g., manual permission management that a role bot would automate) vs. community-size-driven (which migrating platforms will not reduce). See the moderation guide reference card. | Platform admin time often scales with community size, not platform quality. A 500-member community requires more moderation regardless of platform. Measure admin time per member rather than absolute hours to determine if the platform is the actual driver. |
| Member acquisition blocked by platform | No public-facing SEO-indexed landing page possible on the current platform AND organic search is a primary acquisition channel or target acquisition channel — meaning the current platform’s closed architecture is actively preventing member acquisition at scale | SEO acquisition is not yet a channel in use and community is <12 months old. Build the content library and SEO presence on a separate site (as a subdomain or separate domain) before migrating for an SEO reason — the content and domain authority will survive a platform migration; the member acquisition value is in the content, not the community platform. | Most operators who migrate for SEO reasons have not yet built the content library that would drive SEO traffic. Migration does not produce SEO value — content does. Migrate for SEO only after the content strategy is validated on the current platform. |
| Member activation rate consistently below benchmark | Stay and optimize first. Week-1 activation below 30% is addressable on most platforms with a structured onboarding sequence before migration is justified. See the member onboarding reference card and test a three-touch automation sequence for 60 days before attributing low activation to the platform. | Platform migration is the correct lever for activation only when activation is high during the first 7 days (driven by onboarding automation) but drops sharply between day 7 and day 30 in a pattern consistent with the platform’s UX failing to support habit formation — e.g., no persistent content library, no mobile app with push notifications, or no event discovery mechanism. | Operators confuse low activation (a sequence problem) with low engagement at day 30–60 (potentially a platform problem). Separate the metrics: activation rate at day 7 vs. engagement rate at day 30–60. Platform migration addresses the latter if the root cause is habit-formation mechanics — it does not address the former. |
| Founder/operator personal preference for new platform | Stay unless validated by member signal. Operator preference for a new platform is not a migration justification. Run a member survey asking directly about platform satisfaction before initiating migration planning. If >40% of members cite specific platform frustrations, that validates operator instinct. If <20% cite platform frustrations, the migration will be operator-driven friction imposed on a community that did not ask for it. | Operator preference can be acted on when combined with at least one hard trigger: churn >5% for 3 months, cost >15% of ARPU, or a critical integration gap. Preference alone does not pass the migration cost-benefit threshold. | The new platform always feels better to the operator because the operator discovered it during a period of frustration with the old one. Members who did not discover the new platform in that emotional context will not share the operator’s enthusiasm on cutover day. Treat operator preference as a flag to investigate, not a decision. |
Table 2: Platform capability comparison — Slack, Circle, Discord, Mighty Networks, Kajabi, Skool
Eight dimensions that determine whether a platform supports paid community activation, retention, and scale. Ratings reflect the platform’s native capability without third-party integrations — “High” means the capability is built-in and requires no external tool; “Medium” means a partial native solution exists but third-party augmentation materially improves it; “Low” means the capability requires a third-party tool or is absent. Costs are representative for a 200-member community at the platform’s standard paid tier as of early 2026 — confirm current pricing directly with each platform before migration planning.
| Dimension | Slack | Circle | Discord | Mighty Networks | Kajabi | Skool |
|---|---|---|---|---|---|---|
| Native onboarding flow for new members | Low — no native onboarding checklist or guided first-session flow; all onboarding must be built via bot automation or third-party tool | High — native guided checklist visible on first login; configurable steps; 38–52% week-1 completion rate for communities that configure it | Medium — role-gate onboarding (rules acceptance, reaction to gain access) is built-in but transactional; not guidance-based; 44–58% completion in paid communities | High — native onboarding flow with profile setup, interest tagging, and group discovery; completion rates of 45–62% in communities with >3 active groups | Medium — native course-first onboarding; strong for content-first communities, weaker for conversation-first communities where the first activation step is a post, not a lesson | Medium — native progress-based onboarding tied to the classroom module; effective for course-integrated communities; weaker for pure discussion communities |
| Day 0 DM effectiveness (automated, <15 min from join) | High — Slack DMs have the highest same-session read rate (72–85% within 15 minutes for automated messages) because the channel is messaging-first and members check DMs habitually; requires third-party automation (Foothold or equivalent) to fire within 15 minutes of join | Medium — Circle DMs are delivered natively but read rates are 22–35% in the first session; members receive DM notifications via email or app push, neither of which produces the same-session engagement rate of Slack | Medium — Discord DMs from bots have variable delivery (user DM settings block bot messages by default in some configurations); effective for communities with Discord-native members; less effective for non-gamer professional audiences | Medium — Mighty Networks supports automated welcome messages but Day 0 DM read rates (28–42% same session) are limited by the platform’s notification architecture and lower app-open frequency than Slack or Discord | Low — Kajabi’s messaging is email-first; in-app DMs are secondary; day 0 automation is best implemented as a triggered email sequence, not a DM — email Day 0 read rates are 28–38% in the first session | Medium — Skool community DMs function but the platform is optimized for course delivery rather than conversation; Day 0 DM automation requires Zapier integration; read rates not independently benchmarked at scale |
| Analytics depth (member behavior, activation, retention) | Low — Slack provides message counts per channel and member activity summaries; no native cohort analysis, activation funnel, or per-member lifetime engagement tracking; requires third-party analytics or Slack audit logs via API | High — Circle’s analytics include member activity timelines, post frequency, space engagement by member, and configurable member health scores; the most analytics-native platform in this comparison for community-first operators | Medium — Discord provides per-server analytics (member count, message count, channel activity) but no per-member activation tracking; bot-based analytics tools (e.g., Statbot) provide deeper per-member data via third-party integration | Medium — Mighty Networks provides member activity summaries, event attendance, and content interaction data; activation funnel tracking is less granular than Circle; no per-member DM delivery confirmation | High — Kajabi’s analytics cover product completion rates, email open rates, purchase history, and customer lifetime value; strong for course-completion and revenue analytics; weaker for community engagement analytics specifically | Medium — Skool provides member points, activity level, and course completion tracking; engagement analytics are gamification-centric (leaderboard position, points per action) rather than behavioral health metrics |
| Mobile app with push notifications | High — Slack’s mobile app has the highest daily active usage rate of any platform in this comparison for professional audiences; push notification delivery rates are 78–88% for users who have enabled them | High — Circle’s mobile app supports push notifications for DMs, space activity, and event reminders; app engagement is materially lower than Slack for non-creator audiences but higher than Mighty Networks | High — Discord’s mobile app has high daily active usage for Discord-native communities (gaming, crypto, creator); push notification delivery is 72–85% for users who have not disabled server notifications | Medium — Mighty Networks has a white-label mobile app available on paid tiers; push notification delivery rates are lower than Slack or Discord due to lower app-open frequency in professional audiences | Medium — Kajabi has a mobile app but it is course-delivery-first; community engagement features in the mobile app are secondary; members primarily use it to consume content, not to post | Medium — Skool has a mobile app with community and course features; engagement is primarily web-based; mobile push notification effectiveness not independently benchmarked at the scale of Slack or Discord |
| Public-facing SEO-indexed pages | Low — Slack communities are fully gated; no public-facing indexed pages; all SEO value must come from a separate site or marketing page; community conversations are not crawlable | Medium — Circle spaces can be set to public (indexed by search engines); individual posts can be public; effective as a hybrid public/private model where some content is SEO-accessible and some is members-only | Low — Discord servers are fully gated; no public-facing indexed content; SEO value must come from a separate site; Discord channels are not crawlable | Medium — Mighty Networks supports public landing pages for the community and public group discovery; individual posts are generally gated; some public event pages are indexed | High — Kajabi’s full website builder supports SEO-optimized public pages, blog, and landing pages natively; the platform is designed for public marketing + gated community in a single tool | Medium — Skool communities have a public landing page that is indexed; individual posts are gated; the public landing page is configurable but limited in design flexibility compared to Kajabi or a standalone site |
| Content permanence and searchability | Low (free tier) / High (paid) — Slack free plan limits message history to 90 days; paid plans (Pro and above) offer unlimited history; search within Slack is powerful for keyword search but does not surface related content by topic; no native content library separate from message history | High — Circle posts are permanent, searchable by keyword and space, and organized into a content library by default; content does not decay into a message stream; members can find a post from 18 months ago as easily as one from last week | Medium — Discord messages are searchable but decay into the stream; pinned posts and forums channels (Discord’s structured thread format) improve permanence for priority content; not a natural match for communities where long-form reference content is a primary member value | High — Mighty Networks separates posts, articles, and resources into distinct content types; all are permanent and browsable by topic; the content library is a core member value proposition, not a side feature | High — Kajabi’s course and content library is fully permanent, organized by product and module, and searchable; community posts are less structured but content products (courses, podcasts, challenges) are highly persistent | High — Skool’s classroom module is fully permanent; community posts are permanent but organized chronologically rather than by topic; the combination of structured course content with community discussion is Skool’s core differentiator |
| Native payment and access control | Low — Slack has no native payment integration; membership payment and access management requires a third-party tool (Memberstack, Outseta, or equivalent) that provisions and de-provisions Slack workspace access based on payment events | High — Circle has native payment integration (Stripe) with automated access provisioning; supports tiered membership, free trials, and cohort-based enrollment; member access is automatically removed on payment failure after configured grace period | Low — Discord has no native payment integration; access control requires a third-party bot (e.g., Patreon integration, Member.io, or custom webhook) to assign and revoke roles based on payment status | High — Mighty Networks has native Stripe integration with tiered pricing, free trials, and automated access management; the platform handles trial-to-paid conversion natively without a third-party tool | High — Kajabi has the most complete native commerce stack in this comparison: payment processing, product delivery, upsell, affiliate program, and automated access management are all native; strongest for operators who run courses + community as a combined product | High — Skool has native payment integration with Stripe; access is automatically managed based on subscription status; the payment and access system is intentionally simple (one tier per community) which reduces configuration overhead but limits tier flexibility |
| Representative monthly cost for 200-member community | $87–$150/month (Slack Pro plan at $7.25/active user/month for 200 members; does not include onboarding automation tool cost, which adds $49–$199/month for a managed solution like Foothold) | $99–$199/month (Circle Professional or Business tier; per-member fees apply above member limits on lower tiers; analytics and automations on Business tier only) | $0–$49/month (Discord server hosting is free; cost is in third-party tools for payment management, analytics, and bot automation; total stack typically $49–$149/month for a managed paid community) | $119–$179/month (Mighty Networks Mighty Pro or Business tier; white-label mobile app requires the higher Business tier; lower tiers lack the analytics and automation features relevant to paid community management) | $149–$399/month (Kajabi Growth or Pro tier; all-in-one cost includes website, email, courses, and community; high relative to platforms where community is the primary product, not a component of a broader product suite) | $99/month (Skool charges $99/month flat for one community regardless of member count; predictable cost at small scale; cost-per-member advantage disappears as the community grows and the flat rate becomes low relative to other tiers) |
Table 3: Pre-migration checklist — what to complete before announcing the migration
Five categories of work that must be complete before the migration announcement reaches members. Work completed before announcement preserves operator credibility (members trust that the operator has a plan) and prevents the most common migration execution failures (broken integrations on cutover day, missing onboarding sequences for the first 30 days of new joins, and member data not transferred before the old platform access expires). The time estimate is for a 200-member community with standard integrations; communities with custom Zapier workflows or multiple payment tiers should add 30–50% to integration remapping time.
| Category | Checklist items | Time estimate | Risk if skipped |
|---|---|---|---|
| Member data export | Export full member list with: email address, join date, payment tier, last-active date, and any goal or tag data collected during onboarding. Confirm export completeness by checking export count against payment processor active subscriber count. Archive the export in a location outside the old platform (CSV in Google Drive or equivalent) — do not rely on the old platform remaining accessible post-cutover for data retrieval. | 2–4 hours | Without a complete member export, operators who need to contact non-migrated members post-cutover have no way to reach members who did not complete profile setup on the new platform. The exported email list is the only communication channel independent of both platforms. |
| Content migration | Inventory all pinned content, resource documents, welcome messages, and evergreen posts on the old platform. Categorize into: (a) must migrate — content that is actively referenced in onboarding sequences or linked from the member journey; (b) migrate if possible — content that has received engagement in the past 6 months; (c) archive only — content older than 6 months with no recent engagement that does not warrant full migration. Re-create “must migrate” content on the new platform before cutover. Provide a redirect note in any DM or email that links to old-platform content. | 4–12 hours (depending on content volume) | Members who click on a link to an old-platform resource after cutover and receive a 404 or access-denied error learn immediately that the migration was not well-prepared. One broken link in the onboarding sequence is enough to produce a support ticket and a negative migration impression that the operator then has to recover from personally. |
| Integration remapping | Audit every active Zapier zap, webhook, and API connection that touches the old platform. For each: (a) identify the new platform equivalent trigger/action; (b) build and test the equivalent Zapier workflow on the new platform; (c) run a live end-to-end test (new member joins via payment processor → new platform access provisioned → onboarding sequence fires → operator receives new-member notification) before cutover. Document each integration status in a migration log. Do not disable old-platform integrations until new-platform equivalents are confirmed working. | 4–8 hours | Payment processor integration failure on cutover day means new members who join during the transition period are not provisioned access on the new platform. The operator discovers this when a member emails asking why their payment was accepted but they cannot log in. Recovery requires manual access provisioning and an apology, both of which are time-intensive and create a first impression the operator cannot undo. |
| Onboarding sequence rebuild | Rebuild the full three-touch onboarding sequence on the new platform before cutover: Day 0 DM (fires within 15 minutes of join, confirmed by end-to-end test), Day 3 nudge (post-detection logic confirmed to cover all relevant channels/spaces on the new platform, not just the #intros equivalent), Day 7 operator scorecard (delivery confirmed to operator DM or email). Run the complete sequence with a test account before cutover. Confirm that the sequence covers new members who join during the migration window (between announcement and full cutover) as well as members who join post-cutover. See the member onboarding reference card for Day 0 DM design and the member health score reference card for the post-day-7 monitoring setup. | 4–8 hours | Deferring the onboarding rebuild to post-cutover means the first 30–60 days of new joins happen with no automated onboarding. A community generating 20 new members/month loses 40 members’ activation window during a 60-day rebuild delay — at the 34% activation rate difference between structured and unstructured onboarding, approximately 14 members do not activate who would have with a working sequence. |
| New platform environment test | Log into the new platform as a brand-new member (use an incognito browser and a test email address, not your admin account). Complete every step of the member journey: join via the payment link, receive the Day 0 DM within 15 minutes, complete the onboarding checklist (if native), post in the equivalent of #introductions, subscribe to the recommended channels/spaces. Note every point of friction. Fix friction before announcing to members — friction you notice as a new member is friction every migrating member will also notice, except you have context about why it’s there and they do not. | 1–2 hours | Operators who skip the new-member test miss UX friction that is obvious to a first-time user but invisible to the operator who configured the platform. Examples: the Day 0 DM fires in a channel the member cannot see because they have not accepted the rules gate; the onboarding checklist links to an empty space that has not yet been populated; the payment confirmation email still references the old platform’s URL. |
Table 4: Member communication timeline — six weeks pre-cutover through day 30 post-migration
Seven communication milestones from the internal migration decision through the 30-day post-migration check-in. The timeline assumes a community of 100–500 members and a cutover that happens on a Tuesday or Wednesday (the highest-engagement days for paid professional communities — members are more likely to respond to migration instructions on a mid-week day than on a Friday or Monday). Adjust the timeline but not the structure: the sequence of announcement → preview access → personal reminder → cutover day → straggler outreach is validated regardless of absolute dates. Templates are starting points — the specific language should reflect the operator’s voice and the community’s culture.
| Milestone | Timing | Content and channel | Success signal |
|---|---|---|---|
| Internal decision + core member preview | Week −6 (6 weeks before cutover) | DM to 3–5 most-active long-term members (your unofficial community leaders) explaining the migration decision, the timeline, and the reasons. Ask for their honest reaction. Incorporate feedback. These members will be asked to be “migration guides” — visible early adopters who post about the new platform publicly in the community, reducing the perceived risk for members who are skeptical. | At least 3 of 5 contacted members respond positively and agree to participate as migration guides. If 0–1 agree, the migration has a community-sentiment problem that needs to be addressed before announcement — investigate whether the migration decision is being driven by operator preference rather than member pain. |
| All-member announcement | Week −4 (4 weeks before cutover) | Post in the community (pinned) + email to full member list. Content: why you’re moving (specific, honest, not corporate-speak — members can tell the difference between “we are moving to better serve you” and “Slack costs too much at our current size”), what is changing (platform interface, access URL, any lost features), what is NOT changing (membership price, content, the community itself), timeline with specific cutover date, and one clear next step (join the new platform now to get early access — the preview period reduces cutover-day friction). Subject line for email: “We’re moving [Community Name] to [New Platform] on [Cutover Date] — here’s what changes.” | 40–60% of members click through to the new platform preview within 7 days of announcement. Less than 40% suggests the announcement landed as low-urgency — send a personal follow-up to non-clickers in week −3. |
| Preview access period opens | Week −4 to Week −1 (open immediately after announcement) | New platform is accessible to all members at the preview URL. The onboarding sequence is live (Day 0 DM fires on first login, not on payment join date — configure the trigger for existing members to be “first login to new platform”). Migration guides post their first impressions in the new platform. Operator is active on both platforms during this period — the old platform remains fully operational. Members who move early receive a “migration pioneer” acknowledgment (a pinned thank-you post naming them) — social proof for late adopters. | 30–45% of members complete profile setup and first post on new platform during the preview period. Members who do not engage with the new platform during the preview period are the highest churn risk at cutover — flag them for personal outreach in week −1. |
| Pre-cutover reminder | Week −1 (7 days before cutover) | Email to all members who have NOT yet logged into the new platform (use the new platform’s member login log or compare member list against new-platform profile list). Subject line: “[Community Name] moves to [New Platform] in 7 days — one step to keep your access.” Content: the single action required (click the join link and set up your profile), the specific date the old platform access ends, and a personal note from the operator (“If you have any trouble, DM me directly” with the operator’s contact method). For communities with active Slack channels: pin the reminder in every active channel, not just #announcements. | Email open rate >50% (use a subject line A/B test if under 40% in preview). The goal is to reduce the population of members who reach cutover day without having logged into the new platform to <15% of total members. |
| Cutover day | Week 0 (Tuesday or Wednesday recommended) | Old platform access is set to read-only at 12:00 UTC (allowing members to retrieve any saved content but preventing new posts that will not be archived). New platform is the only active community channel. Operator posts a cutover announcement on both platforms simultaneously: “We’re officially live on [New Platform]. Old platform is now read-only. [Single action: join the new platform]. I’m here if you have any questions.” Operator is available for personal DMs on both platforms for the full cutover day. Monitor the new platform for first posts from members who have not been active during the preview period — respond to every first post within 2 hours on cutover day. | 50–65% of total members active on new platform within 48 hours of cutover. Members who are not active within 48 hours should receive a personal DM from the operator (not a bulk email) within 72 hours of cutover. |
| Day 7 straggler outreach | Day 7 post-cutover | Pull the list of members who have not logged into the new platform by day 7 (from new-platform member activity log). For each: send a personal DM from the operator’s email (not a bulk campaign) — “[Name], I noticed you haven’t moved over yet — totally understand if the timing is tough. [New platform] is live and [specific thing they cared about / contributed to on old platform] is already there. Is there anything that would make the move easier?” This is a retention conversation, not a migration task — some members will tell you they are cancelling regardless; the goal is to recover the ones who are waiting for someone to personally invite them. | 30–50% of personally-contacted non-migrators log in within 72 hours of personal outreach. Members who do not respond to personal outreach by day 14 have a >70% probability of cancelling at next billing date. See the member win-back reference card and the offboarding reference card for handling planned and unplanned departures. |
| Day 30 migration retrospective | Day 30 post-cutover | Send a brief survey to all members (3 questions: How smooth was the migration experience on a 1–10 scale? What is one thing that is better on the new platform? What is one thing you miss from the old platform?). Post a public retrospective in the community: how many members migrated, what the operator learned, and one specific improvement made based on member feedback during the migration. Transparency about the migration experience — including what was harder than expected — is the highest-trust signal the operator can send: it demonstrates the community is led by someone who is honest about tradeoffs, not just celebrating wins. | Survey response rate >25% indicates the community is re-engaging post-migration. A response rate <15% at day 30 suggests the community is in a low-engagement phase that requires a programming intervention — see the engagement benchmarks reference card for the signal thresholds and intervention options. |
Table 5: Activation impact by onboarding structure type
How a platform migration affects week-1 activation rates for the first 90 days post-cutover, broken out by the onboarding structure the operator runs on the new platform: high-touch (operator-led personal DM + manual check-ins), semi-managed (automated three-touch sequence + operator intervention for flagged members), and self-serve (no automated sequence; member activates through platform’s native onboarding checklist alone). Activation is defined as: first post in a public channel/space, completion of at least one onboarding checklist step, and response to the Day 0 DM goal question — all within 7 days of joining. Figures are benchmarks from communities of 50–500 members, not a guarantee; actual results vary based on community niche, member technical proficiency, and operator engagement level.
| Onboarding structure | Week-1 activation pre-migration (on old platform) | Week-1 activation months 1–2 post-cutover (adjustment period) | Week-1 activation months 3–4 post-cutover (stabilized) | Primary risk during adjustment period |
|---|---|---|---|---|
| High-touch (operator-led personal DM, <15 min from join) | 52–68% | 38–52% — drop driven by operator attention split between migration management and new-member onboarding; personal DM timing degrades when operator is handling migration-related support tickets simultaneously | 55–72% — stabilizes above pre-migration baseline if the new platform’s DM channel is higher-engagement than the old one (e.g., Slack-to-Circle migrations typically stabilize below Slack baseline; Circle-to-Slack stabilize above Circle baseline) | Operator bandwidth collapse: the first 8 weeks after cutover are the highest-support-request period in the community’s lifecycle. Personal DM timing degrades first under load. Mitigation: hire or designate a community manager to handle migration support tickets so the operator can maintain new-member DM timing. |
| Semi-managed (automated three-touch + operator intervention for flagged members) | 44–62% | 28–44% — drop driven by onboarding sequence gap during the rebuild period; if the sequence is rebuilt and tested before cutover (per the pre-migration checklist), the drop is 8–12 percentage points; if rebuilt after cutover, the drop is 18–28 percentage points covering the entire rebuild window | 48–65% — stabilizes near pre-migration baseline; full recovery to baseline depends on whether the new platform’s DM read rates are equivalent to the old platform’s (they often are not; see Table 2) | Onboarding sequence rebuild gap: the period between cutover and a fully operational onboarding sequence on the new platform is the highest-risk window for new-member activation. Every day the sequence is not running, new members who join are receiving no structured activation support. See the onboarding metrics reference card for the monitoring setup. |
| Self-serve (platform native onboarding checklist, no automated DM sequence) | 18–32% | 12–22% — the native onboarding checklist on the new platform is unfamiliar; members who completed the old platform’s checklist will not automatically find or complete the new one; the platform’s own onboarding UX is visible for the first time during the member’s most distracted session (migration week) | 18–30% — stabilizes near the pre-migration baseline; self-serve activation does not benefit from the new platform’s DM effectiveness because no DMs are being sent; the platform’s native checklist completion rate sets the ceiling | No activation leverage during the worst window: self-serve onboarding produces the lowest activation on a normal day; during a platform migration, the combined friction of new platform learning + no personal outreach produces the lowest migration retention in this table. The post-migration period is the highest-ROI moment to introduce a structured onboarding sequence if the community has not had one — new members on the new platform are starting fresh, which makes a Day 0 DM feel natural rather than unexpected. |
Table 6: Migration failure modes — six common execution errors with prevention and recovery
The six failures most commonly reported by paid community operators who have completed a platform migration, ordered by frequency of occurrence. Each failure has a prevention action (taken before or during the migration) and a recovery action (taken after the failure has occurred). Failures 1–3 are preventable with the pre-migration checklist (Table 3); failures 4–6 are recoverable but require operator time investment that is significantly higher than the prevention cost. See the member retention reference card for the broader retention framework these failures intersect with.
| Failure mode | Observable signal | Root cause | Prevention | Recovery |
|---|---|---|---|---|
| Payment integration gap produces new-member access failure on cutover day | Member emails or posts that they completed payment but cannot access the new platform; operator receives multiple access-request tickets on cutover day | Zapier zap or webhook connecting payment processor to new platform was not fully rebuilt and tested before cutover; old-platform integration was disabled but new-platform integration was not confirmed live | Run a live end-to-end payment test (real $1 charge to a test Stripe account → new platform access provisioned → Day 0 DM fires) before disabling old-platform integrations. Confirm at the “integration remapping” checklist item in Table 3. | Manually provision access for each affected member within 2 hours of the report. Send a personal apology DM from the operator including a specific fix and a bonus (one month free, access to a premium session, or direct operator office hours) — not a generic “sorry for the inconvenience.” The operator who responds personally and specifically recovers member trust at a much higher rate than one who sends a bulk apology email. |
| Onboarding sequence does not fire for existing members who join the new platform during preview period | Week-1 activation rate on the new platform in months 1–2 post-cutover is materially below the pre-migration baseline; members in the preview cohort report they never received a Day 0 DM | Onboarding automation was configured to trigger on payment join event, not on “first login to new platform.” Existing members who migrated did not go through the payment flow, so the trigger never fired for them. | Reconfigure the Day 0 DM trigger before preview access opens: the trigger event should be “member logs into new platform for the first time,” not “payment confirmed.” New members who join via the payment flow will still trigger the DM because their first login follows immediately after payment — the trigger is not double-firing, it is covering both cases. | Pull the list of members who joined the preview period without receiving a Day 0 DM. Send a manual Day 0 DM sequence from the operator to each: “[Name] — I noticed you moved over during the preview period but I never sent you a proper welcome on [New Platform]. A bit late, but: [goal question] + [3-step checklist].” The delayed personal DM produces a 28–42% response rate even when sent 7–14 days after the first login, because it demonstrates operator attentiveness. |
| Content links from onboarding sequence break after cutover | Members report 404 errors or access-denied pages when clicking links in the Day 0 DM or welcome email; support tickets reference specific broken links; new-member activation rate is suppressed because the first CTA in the sequence does not resolve | Old platform URLs in the onboarding sequence were not updated to new platform URLs; or new platform content was not published at the expected URL before the onboarding sequence went live; or the new platform reorganized content during the preview period, changing URLs after the sequence was configured | Audit every URL in every automated message (Day 0 DM, Day 3 nudge, Day 7 scorecard, welcome email flow) and confirm each resolves on the new platform before cutover. Do this as a logged-out user — some platforms show content to logged-in members that is access-gated for logged-out users, and the preview-period test may have been done while logged in. | Fix the broken URLs immediately on detection. Send a correction DM or email to all members who received the sequence with broken links: “Quick update: the link in your welcome message now points to [correct URL]. Sorry for the confusion — I fixed it as soon as I caught it.” The correction DM is a second touchpoint that can be used to re-ask the goal question to members who did not respond to the first one. |
| High-tenure members do not migrate and cancel at the next billing date | Month-2 or month-3 churn spike in members who have been in the community for 6–18 months; cancellation reason in exit interviews cites “didn’t want to move to a new platform” or “lost momentum during migration” | High-tenure members have the most invested in the old platform’s content history, social connections, and behavioral habits. They are also the members most likely to be posting monthly rather than weekly — which means they were less likely to see the migration announcements and less likely to have a crisis-of-absence motivation to migrate quickly. The migration required them to recreate habits they had already formed, without providing a compelling reason to do so. | Identify high-tenure members (>6 months, monthly active) before the migration announcement. Contact them individually before the all-member announcement, explain the reason for the migration, and ask directly: “What would make this move easy for you?” Incorporate specific answers (e.g., “I need the resource thread from #resources to be in the same place”) into the migration plan. These members need to feel like the migration was designed with them in mind, not despite them. | For high-tenure members who cancel citing migration friction: offer a personal 1:1 with the operator to understand what they lost in the migration and whether it is recoverable. If the lost value (a specific content thread, a particular channel, a connection with another member who also left) is not recoverable, honor the cancellation gracefully and ask permission to reach out in 60 days. Members who cancel due to migration friction — not content or price dissatisfaction — have a 25–40% re-join rate when personally contacted 60 days after departure if the migration friction has been resolved. See the member win-back reference card for the re-engagement sequence. |
| Onboarding sequence fires for migrated members AND for new members, producing duplicate DMs | Members report receiving two Day 0 DMs; existing members receive a “welcome to the community” message that references them as new members when they have been members for 12 months; support tickets express confusion about whether their membership reset | The onboarding sequence trigger for “first login to new platform” does not distinguish between new members (who have never been in the community) and existing members (who are migrating). The same sequence fires for both, but the content of the Day 0 DM references “welcome to the community” language that reads as false for a member who has been active for a year. | Configure two onboarding sequence branches: one for members whose join date on the payment processor is within the past 7 days (genuine new members) and one for members whose join date is older than 7 days (migrating members). The migrating-member sequence should use “welcome to [New Platform]” rather than “welcome to [Community Name]” and should reference the member’s history (“I see you’ve been a member since [join month] — I’d love to know what brought you over to [New Platform] so quickly.”) | Send a correction DM to members who received the wrong sequence: “[Name], ignore my previous message — you’re obviously not new here, and I shouldn’t have sent you a ‘welcome to the community’ note. What I actually meant to say: welcome to [New Platform]. Glad you made the move. What do you think so far?” The corrected personal DM converts a confusion event into a personal touchpoint that reinforces the operator’s attentiveness. |
| New platform's channel/space structure is not rebuilt from the old platform’s most-used channels | Members who migrated are not posting on the new platform; survey feedback cites “I don’t know where to post” or “the channels feel different”; new-platform post rate per member is materially lower than old-platform post rate in the 30 days pre-migration | The operator designed the new platform’s channel/space structure from scratch, optimizing for how the platform works rather than for the behavioral habits members had formed on the old platform. The most-used channels on the old platform (the places where member-to-member conversation happened habitually) do not have a direct equivalent on the new platform, so members lose their posting context and default to not posting. | Before migration, audit the old platform’s channel/space activity data: identify the 5 channels or categories with the highest member post counts over the past 90 days. Build direct equivalents of those 5 on the new platform before cutover. Name them the same or as close as the new platform’s naming conventions allow. In the migration announcement, explicitly map the old channels to their new equivalents: “#wins on Slack → Wins space on Circle. Same conversations, same community, different interface.” See the channel architecture reference card for the full channel design framework. | Post a “where does X go?” guide in the new platform’s most visible space (pinned, announced in the community post) mapping every old-platform channel to its new-platform equivalent, including channels that were merged or retired. Offer a 7-day office-hours session where any member can ask “where should I post [topic]” and receive an immediate response from the operator or migration guide. The office-hours session doubles as a community re-engagement event and produces first posts from members who were lurking on the new platform without finding a posting context. |
Table 7: Post-migration health metrics — what to track for 90 days after cutover
Seven metrics to track weekly for the first 90 days after platform cutover. The first 90 days are the highest-risk window for migration-related churn: members who are on the new platform but not yet behaviorally habituated to it are 2–4 times more likely to cancel at their next billing date than members who have completed three posts and responded to at least one other member’s post. Weekly tracking of these metrics gives the operator an early-warning signal at the individual member level, not just at the aggregate level, which is the input for the personal operator interventions that drive retention. All metrics should be compared against the 30-day pre-migration baseline on the old platform, not against an external benchmark, because community-specific context (niche, member demographics, content type) determines what “normal” looks like for a given community.
| Metric | Measurement definition | Alert threshold | Operator action | 90-day target |
|---|---|---|---|---|
| New platform activation rate (week 1) | % of members who joined via payment in the past 7 days who have completed all three activation events (first public post, Day 0 DM goal-question response, subscription to ≥2 channels/spaces) within 7 days of join. Excludes migrated existing members — this metric is for new joins only. | Below 35% in weeks 1–4 post-cutover, or below pre-migration baseline by >15 percentage points | Check onboarding sequence delivery log: confirm Day 0 DM fired within 15 minutes for each new join in the flagged week. If firing correctly, check the DM read rate — if <40% read within 15 minutes, the new platform’s DM notification setting is not configured correctly for your member base. If sequence is not firing, diagnose the integration and run manual DMs for affected members. | Within 10 percentage points of pre-migration baseline by week 8; at or above pre-migration baseline by week 12 |
| Migrated-member activation rate on new platform | % of members who migrated from the old platform (existing members at cutover date) who have completed at least one public post AND one DM response on the new platform within 14 days of their first login. Tracked separately from new-member activation because the behavioral baseline and onboarding sequence are different for migrated members vs. new joins. | Below 55% by day 14 post-cutover across the full migrated-member cohort | Pull the list of migrated members who have not posted or responded to a DM within 14 days. Segment: members who logged in but did not post (low-friction recovery — personal DM with a specific prompt) vs. members who have not logged in at all (high-churn risk — personal email from operator using the exported member email list, not a new-platform DM they have not seen). | 65–75% of migrated members active (at least one post per month) on new platform by day 90 |
| Month-over-month churn rate (post-migration) | % of paying members who cancel in each of the first three post-migration months, compared to the 3-month pre-migration churn baseline. Measure separately: members who cancel citing platform migration as a reason (recoverable) vs. members who cancel for other reasons (content, price, life change — not recoverable via migration recovery actions). | Churn in any post-migration month >2× pre-migration monthly churn baseline, or >3 members in a single month citing platform migration as cancellation reason | For members who cancel citing platform migration: initiate personal win-back outreach at the 30-day mark (see the member win-back reference card). Identify whether the cited migration friction is addressable: if yes, resolve and report back; if no, honor the decision and request permission for a future check-in. For aggregate churn above threshold: run an emergency member survey to identify any systematic migration failure that has not yet surfaced as a support ticket. | Post-migration monthly churn within 0.5 percentage points of pre-migration baseline by month 3 |
| Posts per active member per week | Total public posts in the week ÷ number of members who logged in at least once in the week. This ratio measures behavioral engagement intensity, not just presence. A member who logs in weekly but does not post is a lurker whose habit is weaker than a poster’s — and lurkers are significantly more likely to cancel at the next billing date without a posting prompt. | Below 70% of pre-migration posts-per-active-member baseline in any week | Review which spaces/channels are receiving posts vs. which are empty. If the posting concentration has shifted (e.g., 80% of posts in one space vs. the pre-migration spread of 40/30/20/10%), the channel architecture may not be replicating the old platform’s posting context. Consider merging low-traffic spaces or running a structured event (AMA, weekly thread prompt) in the empty spaces to reestablish the posting habit. | Posts per active member per week at or above pre-migration baseline by week 8 |
| Day 0 DM response rate (new joins) | % of new members who respond to the Day 0 DM goal question within 48 hours of DM delivery. Tracked weekly as a 4-week rolling average. This metric is a leading indicator of 30-day activation — members who respond to the Day 0 DM goal question within 48 hours activate at 3.1× the rate of members who do not respond. | Below 25% response rate in a 4-week rolling window (pre-migration reference for most platforms: 32–48% for Slack, 18–28% for Circle) | Test the Day 0 DM copy on the new platform: the same message that achieved a 38% response rate on Slack may achieve 22% on Circle because the DM context is different (Slack DMs are conversation-first; Circle DMs may be read in an email notification context where a question requires more friction to answer). Adjust the message to the new platform’s context. See the welcome message reference card for copy testing framework. | Day 0 DM response rate within 5 percentage points of the new platform’s expected benchmark (see Table 2) by week 8 |
| Support ticket volume (platform-related) | Platform support tickets still >2/week after week 8 post-cutover | If platform questions persist past week 8, the issue is platform UX, not member unfamiliarity: the platform has a navigation or discoverability problem that is not resolving through normal usage. Options: create a short video walkthrough of the most common navigation questions and pin it in the new platform; run a live onboarding call for members who joined in weeks 4–8 and still have platform questions; contact the platform’s support team to ask whether there is a known UX issue matching the pattern of your support tickets. | Zero platform-related support tickets per week by week 12 | |
| Migration completion rate | % of members who were active on the old platform in the 30 days before cutover who have logged into the new platform at least once by each checkpoint: day 7, day 14, day 30, day 60. “Active” means posted or responded to a post on the old platform — not merely having a paid account. Members who had a paid account but had not posted in 30+ days before migration should be tracked separately as a churn-risk cohort, not as migration incomplete. | Migration completion below 65% by day 14, or below 75% by day 30, of the pre-migration active member cohort | At each checkpoint, pull the non-migrated active member list and execute personal outreach via the exported email list (not the new-platform DM, which they have not accessed). For each non-migrated member: one personal email from the operator (not a template; use the member’s name and reference one specific thing they contributed to on the old platform) with a single CTA (click here to join the new platform). Three rounds of personal outreach (day 7, day 14, day 30) with no response should be treated as a de facto cancellation for planning purposes — retain them on the billing side until they cancel, but do not include them in the active community count. | 80–88% of pre-migration active members on new platform by day 60; remaining 12–20% treated as voluntary churn for planning purposes |
How onboarding automation survives a platform migration
The platform migration is the single event most likely to break a working onboarding sequence. The sequence that was running reliably on the old platform — Day 0 DM within 15 minutes, Day 3 nudge based on post-detection, Day 7 operator scorecard — depends on three platform-specific integrations that do not transfer automatically: the join event trigger (which the new platform fires differently from the old one), the post-detection logic (which must be reconfigured to cover the new platform’s channel or space architecture), and the scorecard delivery mechanism (which must be tested with the new platform’s member activity data schema). Each of these must be rebuilt and tested independently before cutover.
The argument for a managed onboarding tool like Foothold — as opposed to a custom-built Zapier sequence — is strongest at migration time. A Zapier sequence built for Slack must be fully reconstructed for Circle or Discord: every trigger, every action, every filter, every message template. A managed onboarding tool with native integrations for both platforms can configure the new platform’s sequence in hours rather than days, and the post-detection logic is maintained by the tool vendor rather than by the operator. The operator who migrates from Slack to Circle with a custom Zapier sequence typically rebuilds for 8–16 hours; the operator using a managed tool with Circle integration reconfigures in 1–3 hours. The time difference pays for a managed tool subscription in the migration month alone.
Post-migration onboarding priority: The first 30 days after cutover is the highest-ROI window to improve your onboarding sequence, not just restore it. Members are starting fresh on the new platform, making a Day 0 DM feel natural rather than unexpected even for long-tenure members. Use the migration window to upgrade the sequence: add the goal-based personalization (member’s stated goal from checkout) if it was not in the old sequence, and add a Day 30 check-in for members who activated in week 1 but have not posted in the past two weeks. See how Foothold handles this automatically — including post-migration reconfiguration with the same activation sequence running across Slack, Circle, and Discord.