Community platform migration checklist

Inventory the current system

Finish this inventory before you choose a migration date. For each item, mark whether it can be exported, whether the destination can import it, and whether it is worth carrying forward.

• Members, roles, invitation status, segments, and the fields you still use.
• Paid access, subscriptions, coupons, course enrollments, and progress records.
• Posts, comments, files, lessons, events, messages, and resources members still use.
• Domains, email senders, integrations, analytics, webhooks, and sign-in methods.

Decide what should move

Preserve records that affect access, money, ownership, or member trust. Curate old content more aggressively. A migration is a rare chance to remove stale categories, duplicate resources, and instructions nobody should follow anymore.

• Must preserve: active access, payment records, permissions, consent, and the account details that identify each member.
• Usually useful: current courses, upcoming events, pinned guidance, and frequently used resources.
• Often archive elsewhere: old chatter, expired promotions, obsolete events, and abandoned categories.

Rehearse the member path

• Create a test member with the most common access level.
• Join, sign in again, find the first resource, complete the primary action, and adjust notifications.
• Test one unusual case: a paid member, moderator, course learner, or person changing email addresses.
• Write the support response for the two most likely problems before launch day.

Plan the cutover and the first week

Choose when the old system becomes read-only, when invitations are sent, when domains or integrations change, and who makes each decision. Keep the original exports and a written record of configuration changes.

During the first week, watch successful sign-ins, first actions, support requests, and returning members. Fix the problems those numbers show before you add new features.