✓ Established interest groups
✓ Volunteer community teams
✓ Member access and moderator handovers
— Launching a first creator offer
— Course production or LMS migrations
— Agency software resale
— Guaranteed community growth
Draw the three relationships
Record where a member pays, where their account exists and what grants access to the intended community space. These may be managed by different systems. Mighty’s documentation describes purchase and access routes that can vary by plan configuration and device. Do not infer that an imported account carries over a subscription or that a successful payment always resolves an access problem.
Confirm the migration scope
Ask whether the proposal moves payment arrangements, member records, content or only some of these. The migration FAQ describes the possibility of moving members and content while retaining payments elsewhere. That option still needs an explicit operational design. Establish who handles cancellation, refunds and access reconciliation; do not ask members to subscribe again merely to make a dashboard look consistent.
Respect different purchase routes
Web and app-store purchase arrangements can have different management paths. Identify the actual route before giving instructions. Do not promise that an administrator can alter a member’s store-managed subscription from the community dashboard. Financial and tax obligations depend on the arrangement and should be checked with the appropriate provider or adviser.
A fictional exception
A member can show an existing subscription receipt but cannot enter a moved space. The helper records the minimum useful context and sends the case to the authorised access owner. They do not charge the member again or declare the payment invalid. The case is closed only when the appropriate owner resolves the specific access relationship and the member can complete the intended task.
Before you close this task
Keep any reconciliation record restricted and avoid copying complete receipts into general planning documents. The acceptance condition is the intended access relationship, not possession of an impressive collection of payment evidence. When a provider controls the relevant change, name that dependency and preserve its actual response status.
Where the safety evidence stops
This guide draws on Mighty Networks migration FAQ, Member purchase and access. Merchant-controlled records describe the provider’s own capabilities, terms or standards; they do not independently validate those claims. These records do not establish independent confirmation of the product claims.
Verify any current price, plan limit, label direction, compatibility rule, or commercial term that would materially change the decision. The dated source ledger shows the underlying records so this conclusion can be checked and updated.
Sources used for this page
These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.
- Mighty Networks migration FAQ — Merchant documentation · mightynetworks.com · Merchant-controlled · checked 2026-09-28
- Member purchase and access — Merchant documentation · docs.mightynetworks.com · Merchant-controlled · checked 2026-09-28