Migration - Vanilla Success

/* * These styles apply ONLY to the header and footer assets. */ * { padding: 0; margin: 0; box-sizing: border-box; } .footer { background: #f5f5f6; color: #555a62; font-size: 14px; line-height: 1.5; padding: 18px 0; } .footer-wrap { padding-left: 18px; padding-right: 18px; max-width: 1236px; margin: 0 auto; } .footer a { color: #0291db; } .footer a:hover { color: #0276b3; } .footer-row { display: flex; flex-wrap: wrap; justify-content: space-between; align-items: center; margin: -3px; } .footer-col { padding: 0 3px; } .footer-col-copyRight { justify-content: flex-start; } .footer-col-logo { justify-content: flex-end; } .footer-col-copyRight, .footer-col-logo { flex: 1; display: flex; } .logo { width: 120px; height: 28px; opacity: 0.6; } @media screen and (max-width: 768px) { .footer-row { display: block; } .footer-col { width: 100%; text-align: center; margin: 6px 0; } .footer-col:first-child { margin-top: 0; } .footer-col:last-child { margin-bottom: 0; } .footer-col-copyRight, .footer-col-logo { justify-content: center; } .logo { margin: 0 auto; } } /*# sourceMappingURL=styles.css.map */

Overview

Vanilla offers full, professional migration services from nearly any platform imaginable. If you provide the data, we’ll figure out how to make it work in Vanilla.

The process below assumes you will provide a database dump. We also perform API-based migrations from cloud services when that is necessary and possible. Talk to your account representative if you require a different type of migration like this.

Estimating your migration

You provide the platform name, version number (if applicable), and number of users & posts for your current community platform.
Vanilla will provide an SFTP drop.
You provide a test dump of your data to the SFTP. This is typically a database dump, but may include additional files like avatars or attachments depending on your platform. Please provide a full dump for an accurate estimate. Vanilla will generally accept an NDA if one is required.
You provide the email address for the user that will become the owner account.
You provide any working username & password combination for testing.
Vanilla will evaluate the data and provide a cost estimate and, if requested, a downtime estimate (how long your forum will need to be offline during the transition).
Vanilla will provide feedback on concerns, limitations, or other needs.

Test migration

Vanilla will import your test dump to a Vanilla forum.
You review the test import and provide feedback on data integrity.
Vanilla makes any corrections necessary.
You provide a list of URL patterns that will need to be 301 redirected (discussions, profiles, categories, etc). We will have a pre-existing list for most common platforms, but be sure to mention any customizations or special URLs you need us to handle.
Vanilla implements the 301 redirects and you test them.
A final migration is scheduled.

Final migration

You place your current forum into read-only mode.
You create a fresh data dump, upload it to Vanilla’s SFTP, and notify your contact(s) at Vanilla.
Vanilla confirms it received your final dump and the final import begins.
Vanilla notifies you when the import is complete.
You verify the import is correct.
You switch over DNS, SSO, and/or any other final switchovers. Consult with your Vanilla contact if you are unsure.
If your forum was previously on a domain not being redirected to your new forum, be sure to 301 redirect the folder (with the entire URL intact) to your new forum.
You’re done. Sweet!

Migration security

Migration data should always be sent to Vanilla via SFTP, available by request to your Account Manager. Data can optionally be encrypted using Vanilla’s Public Key, provided below:

Personally-identifiable information

If a client does not wish to provide email addresses during a migration, we recommend formulating dummy email addresses. We can do this automatically during the import if requested. Example: {uniqueid}@yourdomain.com, where {uniqueid} is your equivalent of our UserID - a non-private, unique identifier for the user.

Most single sign-on services work by matching accounts based on email address. To work in this scenario, the authentication endpoint must construct (or have on record) an identical dummy email address. This allows the seamless authentication of the user against the correct account without using real personal info.

More information is available from our Privacy Policy and our developer docs on data privacy.