Nitro Porter

Data migrations for communities

View the Project on GitHub linc/nitro-porter

Community Migrations

Running a seamless community platform is quite challenging. Here’s some suggestions for making yours successful.

Explain the migration to your community

Weeks or months before your migration, explain the motivations and what value you think the community will get from the migration. Many folks don’t like change, so giving them time to process, ask questions, and maybe even vent a bit are a normal part of the process. You might also learn some things about how your community is using the current software so you can adapt your plans.

Get power users to test the new software

Days or weeks before your migration, invite “power users” of your community to try out a staged copy of it. Solicit feedback and see if there are things you can do to address concerns.

Do a test run

Never “just do” a migration. They’re very, very complex. Take some dedicated time to do a test run and then ideally have multiple folks looking for issues.

Set up redirects for everything possible

Creating 301 redirects between old and new content (so that old bookmarks and links still function as expected) are a huge boon to both your everyday users and maintaining your position in search results.

Move files in advance if you can

If your community uploads images or files, these are typically many times the storage space of the database (content) and will take much longer to transfer between servers. Don’t save it for the end. If you can iteratively move files ahead of time and then only move files uploaded in the last few days at the time of migration, that’s ideal. If that’s too complex, just move them all at once as soon as you put the site in maintenance mode for the final migration.

Minimize downtime

Try to restrict downtime to a day or less. If possible, use a maintenance mode that simply prevents new content from being added instead of completely blocking access while the migration is in progress.

Avoid complexity (like deltas)

If you’re moving a database between systems, do it all at once. Don’t try to do most of it sooner and then only recent content for the final migration. It’s worlds more complex.

Give folks a channel for feedback

After the migration, continue collecting feedback for 4-6 weeks. Folks will discover new issues and this is a prime opportunity to hear about how the new software is working for them and how things could be improved.

Don’t panic, but address what you can

Don’t take all the feedback and bury it! Be selective, but do improve things where you can easily do so. It will strengthen your community.