This article walks you through the steps to complete a Customer Relationship Management (CRM) or Association Management System (AMS) migration.
One goal of an CRM/AMS migration project is a data conversion: converting previous data points that were integrated with the existing CRM/AMS and updating them in the Higher Logic Thrive Community (Thrive Community). During the project you should understand the overall impact to your members.
To understand the impact, one of the deliverables from Higher Logic is a Data Mapping Spreadsheet. One important thing to note from this spreadsheet is which elements of your data are already integrated. With this deliverable and a timetable, customer teams can define a communication strategy with their membership. For example, if you're moving CRM/AMS platforms, they're likely going to have a new login and password, so make sure that this change has been communicated in advance.
The CRM/AMS migration project begins with an email or case with our Support team. Customers are then assigned a technical Project Manager (PM) who starts the process with a kick-off call. This kick-off call serves as an introduction, identifying the scope of the project and stakeholders. This call is not to get into the more technical aspects of the project, but only to identify roles, next steps, and confirm a mutual understanding between teams.
One of the assets delivered to a customer is the Statement of Work (SOW), which outlines the scope of the project, as well as objectives, and the Sample Project Plan, which establishes timelines and the next steps.
For your CRM/AMS migration, assign members of your organization to perform the following roles.
- Project Manager - The person who will serve as the primary contact for your organization and as liaison between Higher Logic and your new CRM/AMS.
- Technical Lead - A person who understands how data functions. This could be a Database Administrator (DBA) or your CRM/AMS Admin. This person should have a good understanding of your previous CRM/AMS system and your new one, and serves as the main resource when there is a question about data.
- Community Lead - A member of your Thrive Community admin team, who understands how your membership functions.
The Project Manager within your organization must delegate an individual who understands your membership. This includes:
- Which members should have access to member benefits
- Are there paid benefits connected through your community?
- Are there fields or information that should be available for use by "authorized" members only?
- Are their pages that should be accessible to only "authorized" members?
- Who are your members?
- What is the impact to your membership if they do not have access to the community?
- Do any Automation Rules or community-specific rules impact your membership?
This may be a role filled by two people, your existing DBA or CRM/AMS manager and a contact from the new CRM/AMS you'll be migrating to. This contact must understand:
- Membership types in the CRM/AMS (what are they called?)
- Field information in the CRM/AMS (what is their ID?)
- The impact of data being written to the CRM/AMS (Activity Sync)
Configuration and testing
The success of the project depends on everyone, and that includes configuration and testing. Higher Logic will configure the test community with settings based on the Technical Worksheet completed by customer teams at the start of the project.
After the test environment is configured, customer teams must test the integrated data in order to ensure a successful CRM/AMS migration.
Testing is required in order to collect feedback from the teams that this CRM/AMS migration is most important to. Without this feedback, Higher Logic can only configure the integration for the production site based on details returned in the Technical Worksheet.
The Sample Project Plan includes which elements in the test account should be reviewed and tested. An overview on what customer teams should be familiar with is discussed below.
Thrive Community uses what are known as Contacts. Contacts can exist as Members or Non-members.
For your CRM/AMS migration and integration for the future, customer teams must understand the following:
- Who are your members?
- What permissions do your members have?
- Should non-members be able to access your community?
Demographics is the label that Higher Logic uses for field information. This can be as simple as First Name and Last Name, but could also contain data like Member Expiration date. These fields are unique to the individual Contact.
Demographics in Higher Logic can impact:
- Member Profiles
- Member Directory
- Member Signatures
- Automation Rules
- Advanced Search values
If demographic keys and values are not compensated for in the Data Conversion process any of the above could be impacted.
Higher Logic Security Groups determine:
- Whether they are a Member or not
- Pages and tools they can access (e.g., Member Directory)
When migrating your CRM/AMS, one thing that teams must understand is what member type, or rule in the CRM/AMS, will determine who should be a member.
If a member record is changed to a non-member status, they will be disabled and their subscriptions will be removed.
- Understand Security Groups
- Control Who Can Access Pages & Content
- Community Group Join & View Permissions
- Manage a User’s Discussion Subscriptions
- How to Subscribe to Discussions
- Real-time Participation Emails
Community Groups in Higher Logic are what your membership may refer to as discussion groups. Community Groups can either be Higher Logic-managed or AMS-managed.
Integrated Community Groups have membership determined by the integration. Those member's roles can also be determined by the integration.
This means the integration can impact:
- Access to a Community Group
- Community Group Permissions
- Workspace voting rights
Upgrade during migration
If your AMS/CRM has to undergo an upgrade during the migration, Higher Logic recommends that the upgrade and migration occur simultaneously; otherwise, create a case.