Migration from SugarCRM (Pro) to SuiteCRM Activity Stream dates incorrect

Hi

I’ve just undertaken a migration from SugarCRM Pro to a SuiteCRM 7.1.4 Max setup. I have manually extracted all the tables and converted as there was a fair bit of customisation on the Sugar side of the data. I did skip some tables that were either a) empty or b) seemed to have pointless test data - like 1 entry.

It all seems to be ok, Accounts and Contacts, etc, but the Activity stream suggests that every entry was created 2341 weeks and 5 days ago which seems like it is based off an epoch date. Where should I be looking to correct this ?

Thanks

1 Like

Hi

I just noted that some of the date values are shown incorrectly as well, e.g. 30/11/-0001 10:00 which tells me it is a clock / date issue. I’ll keep digging.

Hi

Duh!

Export via csv not preserving date formats.

Would that imply a bug in SugarCRM Pro CSV export’s date format ? Or… bug in the manual database extraction date format ?

1 Like

Hi Tony,

Great to see you have migrated. We(both the SuiteCRM team and the community) would greatly appreciate feedback(both positive and critical) on your move from SugarCRM Pro and SuiteCRM, and your user experience with SuiteCRM once you begin to use the features.

Thanks,

Will.

Hi Chris

Not a bug, just the chair to keyboard interface failing again.

The csv export from phpmyadmin is correct, but I used Excel to modify the columns to match the SuiteCRM table structure. Excel by default displays the data as dd /mm / yy h:mm (which is probably based on my location settings) and when you save out from Excel to .csv it takes that display value rather than the underlying value as the ‘text’ to save.

The trick is to force the display to yyyy-mm-dd hh:mm in the Format Cells for all date time columns before saving to the .csv file.

Note that there are some date columns and text columns with dates that are not affected by this, it is only datetime columns in Sugar / Suite that are impacted, and if you are doing a manual conversion then many of the tables do not require any changes and a straight .sql export / import will avoid any complications.