Different reasons can spur the decision to move from one community platform to another, but one thing remains constant — this migration is unlike other migrations.

The challenge for organizations moving from one community platform to the next is creating the least amount of disruption for the existing community and related assets, while reaping the benefits the new platform provides.

We've already worked through some of the questions that will shape your migration strategy, so let's move on to next steps. 

Formulating the Migration Approach

With the migration strategy in hand, you can start developing a detailed plan to guide the migration effort, including the definition of tasks, assignment of resources and determining the schedule. A  common question that comes up at this point is, “what's a ballpark timeline and cost for migration?” 

The answer, of course, is it depends. Several variables will impact both factors such as:

  1. Complexity and volume of content, users, data, customizations and integrations to migrate.
  2. Change to user experience and community structure enhancements.
  3. Addition of new use cases and functionality in addition to migration items (outlined in #1).
  4. Clean-up and retirement of inactive or irrelevant users, groups and content.
  5. Whether we can take a phased approach e.g. migrate, and then enhance.

For communities with fairly limited customizations and data, the migration can be completed as quickly as four to six weeks. More complex community environments — such as those with large amounts of data, user generated content, files, customizations and integrations — often require more time to complete, up to 12 weeks or more. 

Typically the migration process itself is typically organized around  the following steps:

migration approach

Executing the Community Migration

With analysis, strategy and a plan developed, now you're ready to execute. In most situations, one of the most time consuming parts of the migration is moving the users, content and data. 

As outlined in the previous post there are GOOD and BAD ways to do this if you want to preserve the vitality of the community you’ve built. A key success factor is to understand exactly HOW and WHERE the users, content and data are being moved and translated from your legacy community platform to the new community platform. Using extract, transform and load (ETL) tools to facilitate the migration offer significant benefits in many situations.

migration playbook and tools

In many situations, the “when” is as important as the “how” when it comes to migrating legacy community content. For example, in many situations, the following sequence can help facilitate the migration process:

  1. User's profile and identity: In community platforms, user identity and profile (WHO) lie at the center of everything. By migrating and provisioning the user profile first, you can move easily map their original content and data in the old environment to its new location.
  2. Community structure and metadata: Community structure and metadata (WHERE) is key because it defines the location and/or organization of content. This is extremely important, for instance if you were using a group called “Product Support” in your old environment, you will want to recreate this same group in the new community environment so you have a location to move all the relevant content and files here once its provisioned.  
  3. Data, content and files: With your users (#1) and structure (#2) provisioned in the environment you're now ready to move the bulk of the content and files (WHAT) from your target legacy platform to its location in the new platform. You can now start to associate a user’s content from the old environment with their new profile, and ensure that structure and metadata is maintained (where appropriate).

Migration offers a significant opportunity to not only move, but not move dormant or lifeless users, structure or data/content. Use your migration project as an opportunity to effect some spring-cleaning by retiring items that are no longer relevant or active.

4 Final Migration Considerations


As you work to formulate your strategy and plan work to define your timeline first, this should include when your community license is set to renew, typically most vendors require a 30-60 day notice period if you do not plan on renewing.

User Experience

Existing users are accustomed to the user experience, architecture, features and functionality of the current community platform. Structure migration of the community in a manner where the future state causes minimal disruption and enhances overall experience.

Community Structure

While there are similarities different community constructs and functionality differ, invest in mapping your existing use cases/features to new environment and documenting gaps, items to retire in favor of new feature or changes.

Future Opportunities

Do your homework and ensure that you're not only addressing the short term issues in your current environment, but picking new community platform with a compelling roadmap that can grow with your business.