Showing results for 
Search instead for 
Do you mean 
Community Home Request Access Read Blogs Share Your Ideas Search Community View My Settings
Copper Super Contributor
Posts: 33
Registered: ‎11-26-2009

Re: Migrating data to SalesLogix

When you say "flat SF representation," does that mean you're getting one CSV file from SalesForce with all the objects in it, or multiple CSV files, one for each object? It's multiple files, right?


Depending on how much you're trying to bring in, you might actually be better off importing the CSV files into MS Access first - Access is set up better for that, and you'll be able to verify the integrity of your ID links before you try to import into SalesLogix, which is going to want to store its own IDs.


In fact, I've heard enough scare-stories about this (well, okay, two) to think that with only 400 accounts and 1500 contacts, you might actually be better off hiring a temp for a few days to enter the data into SLX manually.

New Member
Posts: 4
Registered: ‎02-03-2011

Re: Migrating data to SalesLogix

John, thanks so much for this perspective. That reference to "flat SF representation" is very specifically about the fact tht SF provides for only two addresses per account (both stored in the same "row as the other account info) while the SLX implementation is rather flexible on the number of associated addresses (through storing them in an address table and associating addresses to the account ID).

The good news for us is that we actually migrated the contact and account data from SF already in a quick drive to a mass mailing that merged the two client lists. I'm on a path to sweep in the rest of the useful informaiton so we can close out the SF. I do think our approach will lead us to writing a few DB INSERTs to bring in some of this data rather than relying completely on the import wizard, so I'm trying to keep an open mind on it!
New Member
Posts: 3
Registered: ‎08-28-2009

Re: Migrating data to SalesLogix



We and our partners have done a few SFDC migrations, using Inaport for SalesLogix (from us).


For those that do not know, Inaport is a general purpose integration engine for SalesLogix, SageCRM and ACT. It has been extensively used for migration and integration projects with SalesLogix. Migration projects have included:

* ACT and GoldMine to SalesLogix and SageCRM

* SalesLogix to SageCRM

* SageCRm to SalesLogix

* older SalesLogix and SageCRM systems to current systems, with cleanup.


For SFDC, the easiest approach is to DTS the CSV files into a SQL database, then migrate from there. We can bring in account, contact, history, opportunities, linked documents.


Happy to discuss your requirements in more detail if you are intersted. Contact me: david at inaplex dot com




David Evans

Inaport - CRM Integration


Copper Elite Contributor
Posts: 40
Registered: ‎03-31-2010

Re: Migrating data to SalesLogix

We've done numerous flat file migrations into SalesLogix.  I know there's a number of tools out there which may have starter maps but we have found that unless you plan on using the chosen tool for other integrations, data import after the initial implementation and import then the license costs of the ETL are hard to justify. 


We've found what works the best for us is to use SQL Server Integration Services which is a part of the SQL Server installation.  We've built up most of the data flows required to import basic information (all of it compliant to saleslogix UTC and Synchronization requirements) and then we can customize from there so we end up spending just around the same amount of configuration time as other tools (if not less) without  any cost for additional software.


Somthing you may wish to consider when weighing using the import wizard against a more sophisticated tool is that the Import Wizard is great for a one time import of net new data.  But we have found that to migrate from one system to another is never as simple of turning of the old and firing up the new. 


We have found what often works best is to run both systems in parallel. First there's the initial import and the new system will be in QA/Testing mode for a period of time as users test the new system and validate that data has come across correctly. 


Then there are 1 or more iterative imports/updates to fix the maps to bring in data which was not identified initially. 


Finally there's a last import/update just before the system goes live to bring in the most current data.  Using sophisticated maps which have both insert and update logic helps ensure the cut over process is smooth and stress free. 


Additionally taking this kind of approach also means that even after the old system is shut down and no longer used the snapshot of the old data is kept, since it could happen that there are table or fields which you may not have thought necessary, but someone, somewhere does something crucial once a year and it was missed during the QA/User acceptance testing.  Because you've maintained the old data and used Insert/Update smart maps usually bringing this type of data can be done with a few tweaks of the original maps and you now have the data you need even months later.


Hope that helps.


Best Regards,


James Sutton

James Sutton