Migrating from one platform to another doesn’t have to be a scary process. The key to a successful migration is taking the time to properly verify your data.
At Higher Logic Vanilla (Vanilla), before doing the final migration, we do a test migration (import) of your data.
Then, we ask that you use the test migration checklist to verify that your data has properly transferred in the test migration; refer to Test Migration Checklist, later in this article.
The migration process has several phases. This article examines each phase in detail.
Email notifications
Starting with the test migration and ending with the final migration, email notifications are disabled. This ensures that notifications are not inadvertently sent to users prior to your site being launched.
All email testing should be done on your Staging site.
Key stakeholder
Identify a key stakeholder for this project. This is important because when we do a test migration or final migration, all user data is wiped out, and after each migration, we promote a specific stakeholder to ‘admin’ and reset their password. This person is responsible for updating other team members.
👉 ACTION ITEM: Assign a key stakeholder and communicate to Vanilla.
Data erasure
Content changes, including permissions, will be erased by the test migration and the final migration.
Some customers opt to set up all settings and configurations on Staging in order to have a ‘record of truth’ example. Others take screenshots after the test migration. Others prefer to use spreadsheets.
The important thing is that Vanilla has a clear action plan for all stakeholders for the final migration (more on this in the test migration section).
Pre-migration test accounts
Make sure you have at least one (preferably a few) test account so that you can test the migration from the point of view of an end-user.
👉 ACTION ITEM: Ensure a few test accounts exist.
Production vs. Staging
⚠️ Staging sites do not have adequate storage space to accommodate most migrations. The test and final migrations are done only on your Production site.
Estimate & SOW process
In order to scope out the work, Vanilla requires:
Data migration estimate requirements
- A complete forum database on our sftp (credentials to be sent)
- We strongly recommend compressing databases using zip, gz, or tar.gz. Avoid rar and other less-common formats.
- We prefer MySQL but also accept MSSQL, JSON, CSV, XML, etc. (refer to Acceptable forum data formats, below).
- Label every file and folder being uploaded to include description and date. Examples:
- my_forum_2018-03-27.sql.zip
- my_forum_2018-03-28.bak
- some_users_2018-03-29.csv
- Approximate number of categories
- Approximate monthly traffic (page views)
- Current software version
- Current software name
- Approximate number of posts (discussions + comments)
- Are there attachments to be migrated?
- If yes, number of files and total size
- Are there avatars to be migrated?
- What is the URL of your current community?
- 301 redirects - Please provide us with example URLs from your current community for the following content types (including any variations)
- Discussion URL
- Comment URL
- Category URL
- User URL
- We can do a mass reset of passwords where users set their new password upon first connection.
Will you be using single sign-on?
- If yes: What type(s)?
- Are there additional 301 redirects to be implemented besides the ones above?
- Is there any additional or custom data to be migrated (e.g., blog, wiki, or in-house plugin data)?
Do passwords need to be migrated?
- If yes: We need a non-admin account login credentials for testing. This can be a newly-created account just for this purpose. It must be included in the test dump.
Scope
We must agree on the scope of the migration. When we are in agreement (in terms of scope and price), we will issue you an SOW (Statement of Work).
Vanilla will then send you an SOW with tentative dates.
Our queue is on a first-come/first-served basis, so getting this authorized before the expiration date is crucial in securing the dates that are quoted in the SOW.
Test migration
If you are not a frequent user of your forum, we ask that one of your forum administrators or moderators perform this task because they can likely better determine whether any data is missing.
🛑 IMPORTANT: Do not sign off on the test migration if you’re not certain everything migrated properly!
You must certify the test migration before scheduling the final migration. This is because issues or additional items may arise in the test migration that affect the number of hours required for the final migration. A change to the number of hours required to perform the final migration affects the scheduling (when we can fit it into our queue in turn).
When providing data to Vanilla, you must include attachments (if migrating), avatars if migrating), and any data required in the final migration. You should also review the data requirements (see appendix). A delay in providing the requested and necessary data will directly affect the scheduling of the migration.
It is very important to take note of anything that is unexpected. Your CSM will guide you to determine if an issue is a migration feedback issue or a configuration issue. It will be important to track configuration issues so that we can be sure to have a list of required configuration tweaks for the final migration.
Test Migration Checklist
Many of these items may be unclear or complex, so ideally before we get to the test migration, you should have already completed Dashboard, Gamification, and Moderation training with your CSM.
📝 NOTE: Some of the items and actions listed below might not be applicable to you.
Users
- Do users have correct roles and permissions?
- Can users see and add discussions and comments for the right categories?
- Do users have the correct profile info?
- Are avatars working?
- Are titles/ranks working?
- Are signatures working?
- Do guests have proper permissions?
- Can guests see categories and discussions they should not be able to see?
Content
- Was all content imported? Be sure to check a variety of discussions to ensure everything was migrated.
- Are discussions coherent, in the proper categories, and have the correct number?
- Are attachments working?
- Are private messages coherent?
- Input formatted: does bold work? Do italics work?
- Are there any encoding errors where some characters don’t display correctly?
- Did bookmarks/subscribed threads migrate properly?
- Are header categories set up properly?
Other
- Check that SEO redirects are working properly.
- Test your own registration to ensure it works as expected.
- Is SSO working?
- Are social sign ons working?
- Are new users getting the right permissions?
- Are new users able to see and add discussions and comments in the right categories?
- Is there any other data you were expecting to see but isn’t present? Think about user titles, signatures, and other metadata you may have had.
Migration feedback
You may choose to provide migration feedback in any format (email, spreadsheet, smart sheet), as long as it is clear, organized, and as complete as possible.
For our mutual convenience, Vanilla recommends that you send feedback in/as a batch, rather than multiple communications.
If you are unsure if a piece of feedback is migration feedback or a configuration issue, consult your CSM.
Post-migration configuration
Every community is unique and has unique configurations that must be done depending on the data being imported, addons in use, and your community management team’s personal preferences for the community.
While going through the test migration feedback, it is important to have an organized list that captures any such configurations for the final migration launch day in order to leave less margin for error.
APPENDIX
Providing data
Technical requirements
Acceptable forum data formats (in order of ease)
- MySQL: The database engine that Vanilla runs. Many forums use this engine and will provide a “MySQL” dump for the export (vBulletin, phpBB, bbPress, Drupal, Joomla, and more). Usually, these are .sql files. Also, when you ask for a backup or export, this is what we provide. MySQL is the best and most complete format for migrations to Vanilla, and the one we most often use.
- MSSQL: Some legacy forums run on Microsoft Sequel Server database engine. These dumps are usually .bak files and are more labor-intensive as they require an extra step to be converted to MySQL.
- API: Some cloud solutions may provide API access instead of an export (e.g., Zendesk, Lithium/Khoros). We simply require credentials and a link to the documentation (if we haven’t done it before). We’ll build tooling to fetch the data from different endpoints.
- JSON, CSV, XML, XLS: These text-based data dumps are fine ways to provide data, and often include multiple files. They also involve extra steps to convert to MySQL. Usually custom sites, WordPress comments, and other solutions end up with these.
- PostgreSQL, Redis: These are difficult formats (nodeBB and Discourse use them, respectively). We will accept them, but it extra time is necessary to navigate the process.