Platform Migration & Member Retention
The two-week notice that cost 48%: how one operator rushed a Slack-to-Circle migration — and what personal outreach in weeks 4–8 recovered
The operator running a $99/month paid Slack community for independent product consultants had a cost problem they could calculate down to the dollar. At 198 enrolled members, the community’s monthly Slack Pro bill was $2,178. Monthly recurring revenue from the community was $12,402 — a rough mix of 114 members on the $99 plan, 39 members who had upgraded to an annual plan the prior spring, and a small cohort of grandfathered members at $79. Slack Pro was consuming 17.6% of MRR, and the per-active-member cost was worse: 61 of the 198 enrolled members had not opened the workspace in the past 30 days, making the effective active-member denominator 137 rather than 198, and the per-active-member Slack cost $15.89 per month. The community’s next billing cycle was 19 days away. If the operator could complete the migration to Circle in time to cancel the Slack Pro subscription before the renewal, they would save $2,178 in the next billing cycle alone. That number drove the decision to give members 14 days’ notice instead of the six weeks that every platform migration guide recommended. Ninety days after the cutover date, the operator had migrated 52% of their members, lost 48% to churn, and saved the $2,178 Slack bill. The churn represented approximately $4,800 in lost monthly recurring revenue. They had saved $26,136 in annual Slack costs and lost a minimum of $57,600 in annual member revenue. The calculation, run in retrospect, was not close.
The cost trigger: how 17.6% of MRR becomes a migration decision
The operator had been tracking the Slack Pro cost as a percentage of MRR since the community’s month 14, when the roster had crossed 120 enrolled members and the monthly bill had crossed $1,320. At that point, the cost was 12.4% of MRR — in the evaluation zone by the threshold the paid community platform migration reference card defines, but not yet at the structural margin problem level. The operator had noted the number and moved on.
Between month 14 and month 22 — the month the migration decision was made — two things had changed. First, the member count had grown from 123 to 198, pushing the monthly Slack bill from $1,353 to $2,178 even as the per-seat price had remained constant. Second, and more importantly for the cost calculation, the community’s active-member ratio had declined. In month 14, 89% of enrolled members were active (used a broad 30-day-login definition). By month 22, that ratio had fallen to 69%. The community had grown in absolute enrolled member count but had not proportionally grown its active-member base, which meant the per-active-member cost had grown faster than the per-enrolled-member cost. The 17.6% of MRR that triggered the migration decision was a 42% increase from the 12.4% that had first appeared in the tracking data 8 months earlier.
The operator’s migration decision logic was financially sound. The platform migration reference card’s first table identifies a per-member platform cost above 15% of ARPU as a migrate threshold, and the operator’s per-active-member cost had crossed 16% of the community’s $99 ARPU. The operator had done a basic comparison of Circle’s pricing (the Professional plan at $99/month for unlimited members) against the $2,178 Slack Pro bill and confirmed that migrating to Circle would reduce the monthly platform cost from $2,178 to $99, a 95% reduction. The $2,079/month savings was clear. The problem was not the migration decision. The problem was the timeline attached to it.
The billing-cycle trap: why 19 days became the operative constraint
The operator’s Slack Pro subscription renewed on the 28th of each month. The migration decision was made on the 9th, leaving 19 days before the next $2,178 renewal charge. The operator’s mental model was: complete the migration, cancel Slack Pro before the 28th, save the $2,178. This is the billing-cycle trap that several migration guides document: the upcoming renewal date creates an artificial urgency that compresses the migration timeline to match the billing cycle rather than the member migration cycle. The $2,178 Slack renewal felt like a cost that could be eliminated by acting fast. It was, in fact, a sunk cost that would be paid regardless — the question was whether rushing the timeline to avoid one billing cycle was worth the member churn that compressed notice produces.
The operator chose to give members 14 days’ notice. The announcement was sent on day 1 of the migration window: a Slack message in #announcements, an email to all members, and a personal DM to the community’s 12 most active members. The announcement explained the reason (Slack Pro costs were growing disproportionately), introduced Circle as the new home, provided a signup link, and set a hard cutover date of day 15. After day 15, the Slack workspace would be archived and read-only. New community activity would happen exclusively on Circle.
The operator had not consulted the six-week notice protocol documented in the migration reference card’s member communication timeline table. The protocol exists because migration completion rates are sensitive to notice period length in a nonlinear way: six weeks produces 82–91% completion, four weeks produces 68–76%, and two weeks produces 44–58%. The operator’s 14-day window was below the two-week threshold. The final completion rate — 52% at the hard cutover date — was within the two-week range. Every member who had not completed their migration by day 15 was cut off from the community without transition.
Who migrated in the first 14 days and why
The operator tracked migration completions by day throughout the 14-day window. The pattern was characteristic of what the reference card documents for short-notice migrations: a first-day spike, a mid-window plateau, and a last-day surge that still fell short of the completion rate a longer window would have produced.
Day 1 saw 31 migration completions — the community’s most engaged members, nearly all of whom had read the announcement within hours of posting and had joined Circle within the first afternoon. These were disproportionately members with 12 or more months of tenure: operators, consultants, and community practitioners who had been in the community long enough to have made deliberate investments in their relationships and were not going to let a platform change interrupt them. They knew what they were getting from the community and they acted immediately to protect it.
Days 2 through 9 added 46 completions — an average of 5.75 per day, mostly from members who had read the announcement but had needed a few days to act, either because of their own schedule constraints or because the 14-day window felt sufficient and they had not yet created urgency for themselves. This cohort skewed toward members in their first two months of membership and members with 12 or more months of membership. The months-2–6 cohort was notably absent in this window.
Day 10 brought the first DM requests from members asking whether the 14-day deadline was firm. Several members asked specifically whether they could have more time. The operator confirmed that the deadline was firm: the Slack workspace would be archived on day 15 as planned. The day 10 confirmation produced a brief surge — 14 completions on days 10 and 11 — from members who had been waiting to see whether the deadline would extend. Days 12 through 14 added 13 completions. The cutover day total was 104 migrated members out of 198 enrolled. Migration completion rate: 52.5%.
The onboarding sequence gap: rebuilt three weeks after cutover, not before
The operator’s onboarding sequence on Slack had been a modified version of the three-touch flow: a Day 0 DM sent via Foothold, a Day 3 conditional nudge for members who had not yet posted in any channel, and a Day 7 activation summary sent to the operator each Monday covering new-member status. The sequence had been running for seven months and had produced a 48% Day 30 activation rate for the prior 90 days — a rate in the second-quartile range for paid Slack communities in the $75–$149/month tier according to the paid community member activation rate benchmarks.
When the operator set up Circle, they had focused entirely on the structural migration: creating Spaces that mapped (approximately) to the old Slack channels, importing the member list, and configuring the payment integration. The onboarding sequence had not been rebuilt. The reason was not negligence — the operator knew the sequence needed to be rebuilt and had it on their task list. The reason was time: the 14-day migration window was consumed by the migration logistics, member DMs requesting help, and the operator’s client work, which had not paused for the migration. The onboarding sequence rebuild was the task that kept being pushed to “after the cutover.”
After the cutover, the next eight days were consumed by handling member support questions about Circle, addressing the members who had not migrated and were asking whether their access was truly gone, and managing the administrative tasks of archiving the Slack workspace. The onboarding sequence rebuild happened on day 23 post-cutover — three weeks after the platform switch. In those three weeks, 17 new members had joined Circle through the community’s standard new-member intake process. All 17 had received no Day 0 DM, no Day 3 nudge, and no structured first-week guidance. At the 30-day mark for those 17 members, the operator checked their activation status: 5 had posted in the community (29%). The prior 90-day activation rate for new members with the Slack onboarding sequence had been 48%. The 19-percentage-point gap was the cost of three weeks without an onboarding sequence for the first cohort of new members on the new platform.
The paid community member onboarding reference card documents the activation impact of the onboarding sequence rebuild order: operators who rebuild the sequence before the cutover date maintain activation rates within 3–8 percentage points of pre-migration baseline in the first 30 days post-cutover. Operators who rebuild after cutover see an adjustment-period drop of 18–28 percentage points for semi-managed onboarding sequences, which then recovers to 8–12 points below baseline after the sequence is reinstated. The operator’s 19-percentage-point gap for those 17 members was consistent with the reference card’s documented adjustment-period drop range.
The channel architecture error: Circle Spaces do not map to Slack channels
When the operator had built the Slack workspace, they had organized it into 14 channels: #introductions, #general, #wins, #tools, #pricing-strategy, #client-growth, #positioning, #proposals, #hiring, #events, #resource-library, #hot-takes, #feedback, and #operator-meta. The channels had evolved organically over 22 months and each had its own character: #hot-takes was high-velocity and opinion-forward; #resource-library was low-velocity and archival; #proposals had strict posting norms that the operator had established and enforced over the community’s first year.
When the operator set up Circle, they created 12 Spaces with names that approximately matched the Slack channels: Introductions, General, Wins, Tools, Pricing, Client Growth, Positioning, New Business, Hiring, Events, Library, and Meta. The naming looked like a direct mapping. The architecture was not. Circle’s Spaces are fundamentally different from Slack channels in three ways that the operator had not accounted for. First, Circle Spaces are closer to forums than message streams: posts are threaded by default, persist visibly at the top level, and are expected to be more considered and complete than Slack messages. A community that had built a culture around short, conversational Slack messages found that the same members who had been active in Slack were uncertain about what to post in Circle, because the implicit posting norms were different even though the Space names were familiar. Second, Circle Spaces do not have the sidebar presence and notification mechanics that Slack channels use to signal where activity is happening. In Slack, a member can glance at the left sidebar and see at a glance which channels have new activity. In Circle, finding active content requires navigating to the Space index or the main feed. Members who had been navigating Slack by sidebar habitually found Circle’s navigation model disorienting, particularly in their first week on the new platform. Third, the operator’s #proposals channel had been the community’s highest-value content area: members posted client proposals for peer review, and the norms around constructive feedback had taken the operator 8 months of community management to establish. The Circle “New Business” Space did not inherit those norms. The first month of posts in that Space looked very different from the #proposals channel activity it was meant to replace.
The paid community channel architecture reference documents the principle that governs this failure: channel names are labels for spaces; channel culture is the product of posting history, moderator reinforcement, and accumulated community norms that cannot be migrated by copying the channel name. Operators who migrate platforms expecting that a same-named Space will inherit the culture of its predecessor underestimate the cultural reset that occurs when a community starts fresh on a new platform. The operator in this case study had 14 channels of accumulated culture and replaced them with 12 Spaces that had the right names and no accumulated history.
The 90-day churn picture: who left and when
The operator tracked churn on a weekly basis for the 90 days following the cutover date. The picture that emerged was specific enough to identify the failure mechanisms precisely.
Of the 94 members who had not migrated by the cutover date, 78 cancelled their membership within 30 days. Sixteen did not cancel immediately — they were in a payment-inertia state, still paying but not present on either platform. Of those 16, 11 cancelled between days 31 and 60, and 3 cancelled between days 61 and 90. Two remained enrolled at the 90-day mark, having never joined Circle, and the operator had not yet sent targeted recovery outreach to them.
Among the 104 members who had migrated by the cutover date, 17 cancelled within the first 90 days. The operator examined the exit survey data for these 17 members (14 of 17 completed the exit survey). Seven cited the new platform’s interface as the primary reason for cancellation — they had migrated to Circle but had found the experience sufficiently different from Slack that they had stopped engaging and eventually stopped seeing value in maintaining the membership. Four cited the loss of #proposals as a specific reason: the peer proposal review that had been one of the community’s highest-value activities had not rebuilt itself on Circle in the first 60 days, and those four members had joined the community specifically for that use case. Three cited the absence of an onboarding experience on Circle: they had joined the new platform, found no guidance on what to do next, and had drifted out of engagement. The combination of no onboarding sequence for the first three weeks and a channel architecture that did not preserve the norms and culture of the most valuable content areas had produced churn even among the members who had made the effort to migrate.
The 90-day churn breakdown by tenure cohort was the data point that most clearly identified where the migration had failed. Members with 12 or more months of tenure churned at 12% over 90 days — a rate close to the community’s normal 30-day churn rate and consistent with the reference card’s documentation that long-tenure members tolerate migration friction at higher rates because their accumulated investment exceeds the friction cost. Members in their first 60 days churned at 44% — high, primarily driven by the non-migration of new members who had joined in the weeks before the migration announcement and who had not yet formed enough community attachment to motivate migration effort. But the months-2–6 cohort — 41 members at the time of migration — churned at 71%: 29 of 41 members in that tenure window were gone within 90 days of the cutover.
This was the concentrated loss the reference card’s migration communication timeline table predicts for short-notice migrations applied to communities with a high months-2–6 cohort proportion. The months-2–6 cohort has built enough attachment to care about the community but not enough to make migration friction feel self-evidently worth paying. A two-week notice window gives this cohort insufficient time to form migration intent before the deadline arrives. And unlike new members, who have not yet invested enough to feel the loss acutely, or long-tenure members, who have invested enough to act immediately, the months-2–6 cohort experiences the migration as an interruption to a relationship they were still forming. When the deadline passes and they find themselves cut off from the community, many of them resolve the cognitive dissonance not by rushing to migrate but by reframing the membership as something they were not sure they needed anyway.
What the operator did in weeks 4–8: the personal outreach campaign
By day 21 post-cutover, the operator had the churn picture clearly enough to decide to act. The 94 non-migrated members were distributed across three states: 78 had cancelled, 14 were still enrolled but absent, and 2 had not been categorized. The operator’s outreach strategy distinguished between these populations and between tenure cohorts within each.
For the 14 still-enrolled, non-migrated members, the operator sent personal DMs through the email address on file (the Slack workspace was archived and could not be used for outreach). The messages were specific rather than generic: each message referenced one piece of content, programming, or peer interaction from the prior Slack workspace that was relevant to that member’s stated reason for joining. For the 6 members in this group who were in the months-2–6 tenure cohort, the operator included a named peer on Circle who was working on a problem similar to the member’s stated focus area, and an invitation to a live Circle session scheduled for the following week. The conversion rate for this group was 8 of 14 — 57%. All 8 who re-engaged were still enrolled at the 90-day mark.
For the 78 members who had cancelled before migrating, the operator segmented by tenure and cancellation timing. Members in the months-2–6 cohort who had cancelled within 30 days of the cutover were the priority population: 21 members. For these 21, the operator used the same personal DM approach: specific content reference, named peer connection, upcoming event invitation, and a one-month free offer to lower the re-engagement barrier. The message explicitly acknowledged that the migration had been disruptive: “The two-week timeline was too fast and I know it cost some of you the chance to decide whether Circle was worth it before the deadline hit.” This acknowledgment was not in the standard recovery message template the operator had found in a community management guide — it had been added after the operator reviewed the exit survey data and recognized that several members had cited feeling pressured by the timeline as a factor in their decision not to migrate.
Of the 21 outreach targets in the months-2–6 cancellation cohort, 5 responded to the initial message. 4 reactivated and joined Circle. 17 did not respond or declined. The 19% reactivation rate for this group was within the paid community member win-back reference’s documented 15–25% range for cancellations within 60 days when outreach includes a named peer connection and a programming event anchor. The operator noted that the 4 reactivated members in this cohort were all people who had cited the Circle interface as a deterrent rather than the community itself as the reason for not migrating — the outreach had succeeded with members whose cancellation was platform-driven rather than community-value-driven.
For the 30 members who had cancelled more than 30 days after the cutover (a mix of slow-process non-migrators and migrated members who had later churned off Circle), the operator sent a lower-investment outreach — a single email pointing to a specific recent Circle thread and noting the next live programming event. No one-month free offer was included; the operator had decided that discounting for members who had been on Circle and churned for engagement reasons was not the right recovery approach. Three of these 30 members re-engaged. No discounting was required.
The Circle onboarding sequence: what the operator built three weeks late and what it produced
The onboarding sequence the operator rebuilt on day 23 post-cutover was a direct adaptation of the Slack three-touch flow, replatformed through Foothold’s Circle integration. The Day 0 DM language was updated to reference Circle-specific navigation: the message told new members which Space to introduce themselves in, how to find the feed versus the Space index, and what the tone expectations for the Spaces were (more considered and threaded than the Slack channels had been). The Day 3 nudge was adapted from “you haven’t posted in #introductions” to “you haven’t posted a thread in any Space yet” — a shift that reflected the different posting model of Circle relative to Slack’s message-stream model.
The Day 7 operator scorecard was rebuilt to track Circle-specific activation signals: a new member on Circle is considered activated when they have started at least one thread (not just a reply), have at least one other member who has replied to that thread, and have commented on at least one other member’s thread. This three-signal definition was more demanding than the Slack activation definition (which considered a member activated once they had posted a message in any channel), reflecting the higher-investment posting behavior Circle’s format requires. The operator expected that activation rates would be lower on Circle than on Slack even with a working onboarding sequence, because the activation threshold was higher. This expectation proved correct: the Day 30 activation rate for members who joined Circle after the sequence was rebuilt was 38% — 10 percentage points below the 48% the Slack sequence had achieved, and 9 percentage points above the 29% achieved by the 17 members who had joined with no sequence at all.
The paid community onboarding metrics reference documents the platform-specific activation adjustments that operators should apply when migrating onboarding sequences. The key adjustment for Circle is the thread-initiation barrier: Circle’s threading model requires members to create a discrete post rather than send a message in a stream, and first-time posts on Circle have a higher visible commitment level than Slack messages. Members who are comfortable sending quick messages in a Slack channel may hesitate to post a full thread in a Circle Space. The Day 0 DM language that accounts for this — specifically normalizing the lower-investment reply path (replying to an existing thread) as an equally valid first activation step — improves first-week activation by 8–14 percentage points on Circle compared to a Day 0 DM that only points to thread creation. The operator updated the Day 0 DM in week 6 post-cutover to add this normalization language, and the first two weeks after the update showed a 12-percentage-point improvement in the rate of members who posted (replied or created) in their first 7 days.
The #proposals problem: rebuilding the community’s highest-value content area
The exit survey data had identified the loss of the #proposals culture as a specific reason for churn among four members who had migrated and later cancelled. The operator took this seriously because #proposals had not been just a channel — it had been the community’s primary value demonstration for the pricing-strategy and new-business audience that formed the community’s most valuable ICP segment.
The “New Business” Space on Circle had been low-activity in its first six weeks. The operator diagnosed this as a combination of three factors: the Space name was less evocative than the #proposals framing; the posting norms had not been made explicit in the Space description; and the first-mover problem meant that no member wanted to be the first to share a proposal in a Space with no established culture of constructive peer review. The operator addressed all three. The Space was renamed to “Proposals & New Business” with an explicit pinned description explaining the posting format (proposal context, specific question, what kind of feedback is most useful) and linking to a prior Slack #proposals discussion that had been migrated to a pinned post as an example of the feedback culture the operator was rebuilding. The operator then personally seeded the Space with two proposal-review requests from recent client work, framed specifically as examples of the posting format and the feedback quality they were trying to establish.
This seeding approach — operator-initiated first posts to establish cultural norms in a new Space before expecting member-initiated activity — is documented in the paid community channel architecture reference’s Spaces rebuild protocol. The outcome: Proposals & New Business had six member-initiated posts in the week after the operator’s seeding, four of which followed the posting format described in the pinned description. Three months post-cutover, it was the most active Space in the community by post count, slightly ahead of Introductions and General.
Results at 90 days
At 90 days post-cutover, the operator ran a full accounting of where the migration had landed. The numbers were better than the 48% headline churn rate suggested, because the recovery outreach and the rebuilt onboarding sequence had partially offset the migration losses. They were still substantially worse than a six-week migration would have produced.
Enrolled members: 130 on day 90, compared to 198 at the time of the migration announcement. Net loss: 68 members over 90 days. The operator had added 32 new members in the 90-day period (Circle’s discovery features and the migration’s public announcement had generated some new member intake from people who found the community through Circle’s platform and who had not been Slack community operators). Net enrolled member count was 130, a 34% decline from the pre-migration roster.
Monthly recurring revenue: $9,870 on day 90, compared to $12,402 at migration. The 20% MRR decline was less severe than the 34% enrolled member decline because the new members joining via Circle skewed toward the $99 tier, while the churned members had included a disproportionate number of grandfathered $79 members whose loss reduced the dilution effect. The annual plan cohort had been largely retained — only 3 of the 39 annual plan members had churned in the 90-day period, a retention rate consistent with the reference card’s finding that annual plan members tolerate platform migration friction more than month-to-month members do, partly because they have a higher sunk cost and partly because annual plan members tend to be higher-tenure.
Platform cost: $99/month on Circle, compared to $2,178/month on Slack Pro. The $2,079/month savings was fully realized as of the first post-cutover billing cycle. On an annualized basis, the platform cost reduction was $24,948. The annualized MRR reduction was $30,384. The net financial impact of the migration, at the 90-day mark, was a $5,436 annual net loss compared to the pre-migration state — before accounting for the member churn’s long-term compounding effect on renewal revenue, referral volume, and community quality signals that influence future conversion rates.
Day 30 activation rate for new members: 38% in the post-rebuild period (weeks 4 through 13), compared to 48% pre-migration. The activation gap was primarily attributable to Circle’s higher-commitment posting format rather than the onboarding sequence quality, which the operator considered acceptable given the platform change. The 38% rate was in the top half of Circle-based paid communities documented in the paid community engagement benchmarks reference.
Proposals & New Business activity: Most active Space by post count at month 3. The cultural rebuild had worked. The four members who had churned specifically because of the Proposals culture loss had not returned, but the Space had rebuilt its function with the retained and new member base.
The six-week counterfactual
The operator ran the counterfactual in month four, when they had enough data to model it. Based on the reference card’s documented migration completion rates by notice period and the operator’s own cohort-level churn data, a six-week migration would have produced approximately 84% migration completion rate — 166 of 198 members rather than 104. The months-2–6 cohort, given six weeks, would have had time to form migration intent; the reference card’s communication timeline data suggests this cohort’s migration completion rate increases from approximately 29% (two-week notice) to approximately 71% (six-week notice) because the longer window allows the operator to run a “preview community” engagement strategy that gives this cohort a reason to join Circle while the Slack workspace is still active, rather than forcing a cold migration to an unfamiliar platform under a deadline.
The annualized revenue impact of 166 migrated members versus 104, holding all else equal, was approximately $44,400 in additional retained MRR. Divided by 4 additional weeks of Slack Pro subscription ($2,178 × 1 billing cycle = $2,178), the cost of the six-week migration over the two-week migration was $2,178. The revenue preserved by the six-week approach would have been approximately 20 times the cost of the additional billing cycle. The $2,178 billing cycle the operator had been trying to save was, in terms of its counterfactual cost, one of the more expensive decisions the community had faced.
What the operator would do differently and what they would not change
The operator’s four-month retrospective was written as an internal document and shared with the operator’s peer network. The conclusions were specific rather than generic.
What the operator would do differently: begin with a six-week timeline regardless of the billing cycle. The billing-cycle urgency is a real financial pressure but it is a small cost against the member retention upside of a longer migration window. Calculate the counterfactual before setting the timeline, not after. The formula is straightforward: (additional billing cycles at current platform cost) versus (expected churn reduction from longer notice) multiplied by (average member lifetime value). For the operator’s community, this calculation would have taken 20 minutes and would have produced an unambiguous answer. The operator did not run the calculation before the migration because the billing-cycle pressure made the two-week timeline feel obviously correct. It was the most expensive obvious thing they had done in the community’s history.
Rebuild the onboarding sequence before the cutover date. The operator’s sequence rebuild took 4 hours. The sequence had been pushed to post-cutover because of migration logistics pressure. Those 4 hours should have been the first scheduled task of the migration, not the last. The 19-percentage-point activation gap for the 17 new members who joined in the three-week window without a sequence was the consequence of that sequencing error. The onboarding reference card’s pre-migration checklist lists sequence rebuild as category four of the five migration preparation tasks, with an estimated 2–4 hours and a note that operators who skip it face an 18–28 percentage-point adjustment-period activation drop.
Do not assume channel names transfer platform culture. The Circle Spaces inherited the Slack channel names but not the Slack channel norms. The operator would have rebuilt the Space descriptions, pinned exemplar posts, and seeded the highest-value Spaces with operator-initiated content before opening them to member activity. This takes 6–8 hours of preparation time but eliminates the cold-start problem that caused the “New Business” Space to sit inactive for six weeks.
What the operator would not change: the migration destination. Circle had proved to be a better platform for the community’s actual use case once the architecture and onboarding sequence had been rebuilt. The threaded posting model, while initially disorienting, produced more substantive content than Slack’s message-stream model had. The Day 90 per-post engagement rate (replies per post) was 3.8 on Circle versus 1.2 in the Slack workspace’s best months. The community that had survived the migration, while smaller, had higher per-member engagement levels than the pre-migration Slack community. The operator had paid for that outcome with the migration churn, but the long-run quality trajectory looked different than the trajectory a 200-member Slack community with 31% inactive members had been on.
Frequently asked questions
How do you calculate the cost-trigger threshold for a paid community platform migration decision?
The cost-trigger threshold is the point at which your platform’s per-active-member cost exceeds 15–18% of your ARPU, sustained across at least two billing cycles. Calculate it by dividing your total monthly platform bill by your active member count (members who logged in or posted in the past 30 days — not your enrolled member count, which includes inactive seats that inflate the denominator). If the result exceeds 15% of ARPU, you are in the evaluation zone; if it exceeds 18%, you have a structural margin problem that will worsen as member count grows. The common error is running the calculation against enrolled members rather than active members. A community with 200 enrolled members and 140 active members has a per-active-member platform cost that is 43% higher than its per-enrolled-member cost — and it is the per-active-member cost that matters for the business case, because inactive members are not receiving platform value and are candidates for churn regardless of whether you migrate. The cost-trigger calculation answers whether migration is financially justified; it does not answer how much member churn the migration process itself will produce, which is the variable that most commonly inverts the financial case for a migration that looked straightforward on the cost side. The paid community platform migration reference card’s migration decision table covers all seven trigger signals with migrate and stay-and-optimize thresholds, and the confounding factors that cause operators to misread each signal.
What is the cohort most likely to churn during a paid community platform migration, and why?
The months-2–6 tenure cohort is the highest-risk population in any paid community platform migration. This cohort has invested enough in the community to care about the disruption but not enough to make migration friction feel self-evidently worth paying. New members (months 0–2) are also at risk, primarily because a migration announcement arriving in their first weeks of membership often accelerates a decision they would have made anyway about whether the community was right for them. Long-tenure members (12+ months) have the highest migration completion rate because their accumulated investment — relationships, content contributions, institutional knowledge of community norms — creates a switching cost that exceeds the friction of the migration process. The months-2–6 cohort has made an investment but not a large enough one to generate that switching cost. In a two-week migration window, this cohort’s migration completion rate is approximately 29%; with a six-week window that includes a preview community strategy (inviting this cohort to Circle while the Slack workspace is still active), the completion rate rises to approximately 71%. The 42-percentage-point gap is the value of notice period length for this specific cohort. Operators who cannot extend their notice period should prioritize personal outreach to the months-2–6 cohort specifically — personalized DMs that name one peer connection on the new platform and anchor the outreach to an upcoming programming event convert this cohort at 35–55% during the migration window, compared to 12–18% for a broadcast announcement without personal follow-up.
How do you run personal outreach to recover members who did not migrate after a paid community platform migration?
Personal outreach to non-migrated members divides into two populations: members who are still enrolled but have not migrated (payment-inertia state), and members who have cancelled. Still-enrolled non-migrated members are the highest-priority and most recoverable: they have not made a deliberate decision to leave, they simply have not acted. A personal message within 14 days of the cutover that names one specific community content or peer connection, offers a migration link, and lowers the platform-learning barrier (offer a 15-minute personal onboarding call on the new platform) converts at 35–55%. Cancelled non-migrated members require a different approach. Do not frame the message as migration recovery — frame it as a re-engagement invitation. Reference one specific piece of programming or peer activity happening on the new platform that is relevant to the member’s stated reason for joining, include a named peer on the new platform who shares their focus area, and offer a one-month free period to lower the barrier. Acknowledge if the migration timeline was disruptive — the operator in this case study found that explicit acknowledgment of the compressed timeline improved response rates for the months-2–6 cohort compared to a message that treated the migration as a resolved event. For cancelled members, act within 60 days of cancellation: the 15–25% reactivation rate documented for personal outreach within 60 days drops to 8–12% after 90 days. The paid community member win-back reference card covers the recovery message formula and timing windows by cancellation type.
What is a hard-cutover versus a gradual migration strategy for a paid community platform migration, and when should you use each?
A hard-cutover migration sets a single date on which the old platform is decommissioned and all activity moves to the new platform. A gradual migration runs both platforms in parallel for a defined overlap period — typically four to eight weeks — during which new members onboard to the new platform while existing members migrate at their own pace. The hard cutover is appropriate when a cost trigger makes dual-platform operation financially untenable, when the programming calendar has a natural break that creates a clean transition point, and when the operator can rebuild the onboarding sequence before the cutover date. Its risk is the migration completion rate under a compressed timeline. The gradual migration is appropriate when the community has a high months-2–6 cohort proportion, when programming is continuous with no natural break, or when the operator cannot rebuild the onboarding sequence before decommissioning the old platform. Its risk is member confusion: dual-platform operation for eight weeks creates uncertainty about where canonical activity lives, which can reduce engagement on both platforms and prevent the new platform from accumulating the critical mass of activity needed to feel like the real community. The worst combination — what the operator in this case study executed — is a hard cutover with a two-week notice period: a compressed timeline that gives the months-2–6 cohort insufficient time to form migration intent, and a hard cutover that gives non-migrated members no continued access after the deadline. The platform migration reference card’s member communication timeline table documents the six-week notice protocol that produces 82–91% migration completion rates across six platforms, and the conditions under which a four-week or eight-week timeline is more appropriate than six weeks.