Migrating GoldMine to Microsoft CRM 3.0:
Setting up the SQLTree Project


Step 1 - Load Project File

Download the SQLTree project file: MigrateGoldmineToMicrosoftCRM.zip. Unpack it, start SQLTree and load the contained .stp project file.

Step 2 - Adjust Global Variables

The fist action/node called "Global Variables" has 8 entries. You will have to change their values from their dummy values to the values in your MSCRM database:

Name Description
MigratorUserId Create a user in the MSCRM that will be the owner of the migrated records. Make sure this user has NO records (eg. is a new/clean user) belonging/associated with it, as the migration script/project removes these. This will allow you to run the script multiple times without creating duplicate records. Find this users Id (to be found in the SystemUserBase Table, Column SystemUserId) and enter it into the value field in SQLTree.
MigratorBusinessUnitId The Id of the BusinessUnit you want the migrated records to belong to (to be found in the BusinessUnitBase Table, Column BusinessUnitId).
MigratorOrganizationId The Id of the Organization you want the migrated records to belong to (to be found in the OrganizationBase Table, Column OrganizationId).
ServerName The name of the SQLServer instance.
TempDB The name of the temp/staging database (you can leave this as it is, no change needed).
SQLUserName The name of the SQLServer user with the migration permissions (as mentioned in the online text).
SQLUserPWD The users password. (Waring: This will not be encrypted in the project file, as it is a global variable. You might want to enter these values directly into the Setup actions or use windows integrated security instead)
LimitRecordSQL If you only want to do a test migration of a few contacts, then change this value to something like "TOP 100" (for only 100 contacts).
Leave blank for a full migration.
SourceDB The name of the Goldmine database to migrate the data from.
TargetDB The name of the target Microsoft Dynamics CRM database to migrate to. Usually has the format "[Company Name]_MSCRM".

Step 3 - Change Options

Some of the SQL statements can take a long time (up to 2 hours). The standard timeout is set at 30 seconds. This is way too short for what we need. In order to change this, open the settings dialog in SQLTree [Tools\Options] (or press F10). Select Actions\Setup on the tree to the left and change the Timeout value to something more like 7200 (2 hours). Use an even higher value if your database is very large. The downside on this is that if you should happen to end up with a SQL statement that hangs or the SQL Server stops responding you will have to wait a long time before you can abort.

Step 4 - Run

Run the project (SQLTree->Build\Run), and watch the results.
Running a full migration can take a long time (our 18,000 contacts database took about 7 hours). It will run best on the computer running the SQL Server, but any other that can access it will work fine too, albeit somewhat slower.

Copyright © Jonathan Gill 2007