Move old install to new install

We have a Sage CRM install that dates back to before version 7.1.  I am not sure of the original install date.  It has been upgraded along the way and is currently on version CRM2019.  Unfortunately, the upgrades do not give an old install 100% of the same functionality as a new install. 

The main difference is how a record's primary key is handled.    

In addition since this install is so old, it appears that there are fields that exist in SQL and not in Sage CRM.  Beginning with CRM2019, CRM began showing these fields with brackets [ ] around them in the Sage CRM interface after any change was made to any field or screen. When this occurs, it drops all the main tabs (ie MyCRM, TeamCRM, Reports, etc.). They no longer display.  The only tabs that do display are tabs that have [brackets] around them.  Therefore, the system becomes unusable.  If we do an IIS reset, it removes all the bracket fields and the system operates fine.  However, they come back the next time we make any field changes.

Based on the above, we want to start from scratch with a new install and bring the records over from the old install.  What is the best way to accomplish this?

I am wondering if there are any guideline to follow?  Are there any tools to assist in doing this?

Below are some of the things I think we will need to consider however I am sure there are more.

We will need to keep the primary keys intact so that we do not loose the record relationships (or figure out a way to remap them).

Meta data I bring these over as they existed in the original install?

If we bring the meta data table data over as it existed in the original install, will I be able to add fields that don't currently exist in the new install directly in SQL and then marry them up with a metadata refresh?

What else am I not thinking about that we will need to consider?

Any assistance would be greatly appreciated.  Thank you!

  • Hi Michele 

    One of things we do is on the fresh install is to create some xxxx_OriginalID fields on the entities we want to put data in

    Then from the old data export out minimal company/person/address/phone/email details (e.g.export out people with their Id's as they name, companies with their ID as their name) basically enough data to meet the import rules. 

    Then use CRM to import in the companies and their contacts as normal. BUT map their actual ID values to the new xxxx_OriginalID fields and turn on dedupe on them. This will create the main records and all the phonelink/personlink/addresslink records

    Once in, copy the old database to the same Sql server as CRM_OLD and then use update commands to join the old database to the one where crm.comp_originalid = CRM_OLD.comp_comoanyid you can then bring over all th data you want

    With Opportunities and Cases you can't import through CRM so just import directly into the SQL table making sure to populate the custom ID field, can also have a second custom I'd to represent the old comp ids, you can then do updates to reference the companies based on their comp_originalid to get their proper comp_companyid and join the Case/oppo accordingly

  • Matthew:  Thank you for the recommendation on how to handle the data.  That process is similar to how we handle bringing data into a new install from another CRM system.  Therefore, I am following your recommendation there.  My SQL is way better than my javascript.  Therefore, thumbs up to all this.

    Any recommendations on custom tables?  Can I bring that over from the old install, or will I have a mess?

    Any assistance would be greatly appreciated.  Thanks!

  • If there are custom entities within the old CRM (e.g. 'Project') then I would recreate the entity in the new CRM using the Entity Wizard, and create the fields / screens like that (unless you have it all captured in a component). Whilst it takes time, it's also handy as I tend to tidy up field names - things tend to get reused over time or fields no longer needed, I'll be writing a script to link old and new anyway, just need to keep track of what I renamed things. 

    Then it's all down to a conversation with the customer about how much data they want to bring over. (e.g. just the last 5 years worth) if they want to do some house keeping of data at the same time. So don't, some just want the entire database. 

    The only thing I can't advise on is how to handle documents, I tend to get one of our development team to handle this side of things