Your redesign could wipe out member progress.
The new design took weeks. Members kept learning, joining and posting on the old site the whole time.
Danica LouweUpdated 5 min readDon’t publish the new version over the live site. Take a fresh copy of the live site, bring the new design in with your host’s selected tables option, and leave member data out. Unticking tables with “user” in the name is a good start, but it isn’t enough, because posts, orders and quiz results can live elsewhere. Test on staging, then switch at a quiet time.
Your members didn’t stop while you rebuilt.
A redesign usually starts on a copy of the live site and takes weeks. By launch day, that copy is out of date, and publishing all of it would wipe out everything members did in the meantime.
Both copies have something you need
The new version has your design and updated content. The live site has this month’s progress, enrolments and sign-ups. A normal push keeps one and overwrites the other.
Member data isn’t in one place
Progress, accounts, posts, orders and form entries sit in different database tables. Some have obvious names and some don’t.
Progress is tied to course IDs
If you delete a course and rebuild it during the redesign, it gets a new ID, and members’ progress no longer connects to it.
List what members create before you touch anything.
Think about everything that changes on the live site without you doing it. Each item below needs a plan.
- Course progress, quiz attempts and enrolments.
- New members, changed passwords and profile details.
- Community posts, comments, messages and groups.
- Orders, subscriptions and form entries.
- Points, badges and anything else earned.
- Files members uploaded, such as profile photos and assignments.
- Whether any course was deleted and rebuilt during the redesign, rather than edited.
Copy the design across, and leave the member data where it is.
You take a fresh copy of the live site, then bring in only the parts of the new version that aren’t member data. We use the host’s staging tools, and it’s all tested before members see it.
- 1
Back up, and test the backup
Back up the live site and make sure it restores. Do this before anything else, and again right before the switch.
- 2
Keep the same courses
During the redesign, edit existing courses and lessons rather than deleting and recreating them, so their IDs stay the same.
- 3
Take a fresh copy of the live site
When the design is ready, copy the live site to a staging site. That copy has your latest member data. Turn off its outgoing emails and payment connections so staging can’t contact real members.
- 4
Bring in the design, minus member tables
Bring your new version’s files and database into that staging copy using “selected tables”. Tick all of them, then untick every table holding member data. Searching for “user” finds many of them, but not all. Hosts differ on which way this can run, so check yours first.
- 5
Test it as real members
Log in as a long-standing member and as someone who joined last week. Check their progress, access and posts, plus a payment in your provider’s test mode.
- 6
Switch at your quietest hour
Pause the live site briefly, repeat the copy so nothing is missed, then put the tested version live. Check it again straight away.
The technical version, for your developer
Cloudways has selected tables on both Push and Pull, but Pull only copies from a staging site’s own live parent. So either make the copy with the new design the parent, as in our video, with fresh member data on its staging site, or use Push with selected tables from a staging site holding the design. WP Engine’s Copy Environment lets you select database tables, backs up the destination first, and runs a search and replace on the domain. We ran this on Cloudways in 2023, so check the options on your host today.
- Tables with “user” in the name. wp_users, wp_usermeta (enrolment, older progress, quiz history), wp_learndash_user_activity and its _meta table, and wp_gamipress_user_earnings. Names vary by site and prefix.
- Member data without “user” in the name. wp_comments, wp_learndash_pro_quiz_statistic and _statistic_ref, wp_bp_activity, wp_bp_groups and wp_bp_groups_members, wp_bp_messages_*, wp_bp_xprofile_data, wp_bp_notifications, wp_gamipress_logs, wp_wc_orders and related tables, and form plugin entries.
- The hard one: wp_posts. It holds your lessons and pages, and possibly member content too: forum topics, assignment uploads, and orders on older WooCommerce sites. Neither copy is fully right, and you can’t merge it by ticking a box. Query it for post types created since the build began, then plan how to bring those rows across, keeping IDs and postmeta intact.
- wp_options. It holds settings from the new build and details of the destination site. Confirm URLs, licence keys and payment settings after the copy, including webhook endpoints.
- Files. Don’t overwrite wp-content/uploads wholesale, or you’ll lose what members uploaded since the build started. On Cloudways, use incremental rather than overwrite, and exclude what you can.
- Merging sites. Course, lesson and topic IDs change on import, so progress records would need to be mapped to the new IDs and tested. That’s a migration, not this process.
Watch it done
The process we used on a real Cloudways site in 2023, including the selected tables step. The list of tables below goes further than the video, so read that part before you copy anything.
Questions owners ask
Can I merge two membership sites and keep progress this way?
No. Progress is tied to each course’s ID, and a course moved into another site gets a new one. This method only works when the courses in both copies are the same courses. Merging is a separate job that needs the old IDs matched to the new ones.
What if my host doesn’t have this option?
Ask them first, since the tool may have another name. Without one, a developer can do the same thing directly in the database. Either way, get a tested backup first.
Do I need to close the site during the switch?
Usually for a short time. Anything members do between the final copy and the switch won’t come across, so a brief maintenance window at your quietest hour is safer than losing activity without knowing it.
Will members need to log in again?
They might. Logins depend on security keys in the site’s files and on sessions stored in the database. Your member tables keep their accounts and passwords either way, but warn them in case they’re asked to log in again.
Can I edit lessons on the live site during the redesign?
Try not to. Those edits sit in the same place as your new design and can be overwritten. If you must, keep a list and make the same edits on the new version.
