There have been a number of requests from partners and customers for assistance on migrating ACT! databases to Microsoft CRM 2011, both on premise and online. InaPlex has a lot of experience with migrating ACT databases, as we developed the Sage Migrator product for Sage, which has been extensively used to migrate ACT and GoldMine databases to SageCRM and SalesLogix.

InaPlex has a complete set of profiles available for migrating a standard ACT! version 11 or 12 database to CRM 2011. This series of posts will walk through the process of doing such a migration.

• This first post covers preparation, and importing Account and Contact data
• The second post will cover importing Opportunities
• The third post will cover Activities and History.

Overview

Before embarking on a migration project, it is important to have a look at your data, and how your current CRM system has become embedded (or not) in the work flows of your company.

Issues you may want to consider:

• Should all the data come across, or should this be an opportunity for a “spring clean”?
• What reports are being generated from the data, are they all necessary, can they be improved, how will they be generated in the new CRM system?
• Will you cut over quickly to the new system, or will you attempt to keep both systems running for a period? If the latter, will you need to keep the data in sync between the systems (hint: this can be difficult)
• If the old system was not being used well (there are no reports worth worrying about, a quick cut over is not going to be a problem), why not? And how is the new system going to fix it?

Your channel partner and InaPlex can advise on many of these types of issues; it is important that they be addressed before detailed planning for the migration, because it impacts how the data is brought across.

Preparation

Installation

Because Inaport uses the ACT API, it needs to be installed on a system that has ACT installed. In addition, you need to make sure that you select the version of Inaport built for your ACT version. See the Inaport Download page for details.

Microsoft CRM preparation

Before starting to import data from ACT, you will need to do at least two things in Microsoft CRM:

1. Create any required users. Inaport has the ability to map record ownership from ACT to Microsoft CRM, but the users must be created in CRM first.
2. Create any required custom fields. If you have created custom fields in the ACT database, and you wish to import that data into CRM, you will need to create corresponding fields in CRM.

ACT database preparation

You might also wish to spend some time considering how dirty your ACT data is, and how much data you wish to migrate.

Of particular interest is how companies and company names have been handled in the ACT data. Many ACT databases are based on contacts only. Even in databases that use companies, many contacts may not be linked to a company. This is handled by:

1. importing companies from ACT to MSCRM, and storing the company ID from ACT,
2. then importing contacts. If they are linked to a company, they are linked to the same account in MSCRM. If they are not linked to  a company, then the company name in ACT is used to try and identify the correct account in MSCRM.

This means that before running the import, you may want to validate and clean the company names in ACT.

Connectors

After installation, the next step is to create connectors to the ACT database and Microsoft CRM. There are movies on the web site that show how to do this:

• create a connector for ACT
• create a connector for Microsoft CRM (on premise or on line)

Mapping Users

Inaport gives you the ability to establish a mapping between the users in ACT and the users in Microsoft CRM. This mapping is used by all the standard profiles to map the record ownership from ACT to MSCRM – i.e. a record that is owned by John Smith in ACT will be owned by John Smith in MSCRM, provided you establish the mapping. You can also map multiple ACT users to a single MSCRM user, to handle cases where the ACT user is no longer with the company, for example.

To establish a user map:

1. start Inaport
2. make sure the connectors have been created
3. go to Tools – User Map; select the ACT connector as the source and the MSCRM connector as the target, and click Get Users
4. select a user from the source column, a user from the target column, and Click ‘Add to map’

Importing Companies and Contacts

There are four standard profiles for importing companies and contacts:

1. 01_Company
   Import the company entities from ACT to accounts in MSCRM
2. 02_Contact_with_Company
   Import contacts that are linked to a company in ACT into contacts in MSCRM
3. 03_Contact_NO_Company
   Import contacts that are NOT linked to a company in ACT
4. 04_Secondary_Contacts
   Import the secondary contacts from ACT into main contacts in MSCRM

These profiles are designed to be run in order, but if there are no companies in ACT you can skip 01 and 02.

Secondary contacts are imported to the same account as their primary contact.

A Word about Matching

As noted above, contacts with no company are associated with an account in Microsoft CRM by matching on the company name. By default, the profiles will normalize to company name for matching; this means punctuation and excess spaces are removed, noise words (Inc, Incorporated, LLC, Ltd, Limited, gmbh, sarl, …) are removed, and the result is lower cased.  See screen shot below for an example:

Normalise company name for match

Using name normalisation, “Inaplex Inc” and “InaPlex” will match, but “InnerPlex” and “Inaplex” will not.If you need to handle mis-spelling of company names as well, Inaport has fuzzy match capabilities available – for example, “InaPlex” and “InnerPlex” are an 87% match.

If a contact has no company name, then by default it is imported to an account called “No Company”. This can of course be changed.

Inaport provides the capability to automatically create a new attribute on each entity: “ip_importid”. This is used to store the unique identifier of each record imported from ACT – for example, the Company ID or the Contact ID. This is then sued in subsequent profiles to identify the correct Account or Contact to associate child records with – for example History or Activity.