Upgrade from SugarCRM 6.2.1

Hello!
I’m looking to upgrade/migrate to SuiteCRM from SugarCRM. This is an ancient installation. I think it may have been a Bitnami install in 2008. For the short term I’ve built a virtual Ubuntu 18.04 box and performed an install of SuiteCRM. It is years ahead of where I’m at with SugarCRM.
Some of the basics I’ve already done

  • imaged the server and I’m testing on that only
  • I’ve run the Upgrade Wizard and receive warnings about the

Step1 System Check
File Permissions:
Show Files with Bad Permissions
File Name Permissions Owner Group
/opt/sugarcrm-5.1.0/htdocs/sugarcrm/sugarcrm, 0644 root root
/opt/sugarcrm-5.1.0/htdocs/sugarcrm/sugar1100, 0644 root root
/opt/sugarcrm-5.1.0/htdocs/sugarcrm/root, 0644 root root
/opt/sugarcrm-5.1.0/htdocs/sugarcrm/mysql, 0644 root root
/opt/sugarcrm-5.1.0/htdocs/sugarcrm/localhost, 0644 root root
/opt/sugarcrm-5.1.0/htdocs/sugarcrm/config.php.bak 0644 root root
/opt/sugarcrm-5.1.0/htdocs/sugarcrm/SQLEXPRESS, 0644 root root

Questions:

  • for the error above I’ve been scanning the forums and I think I remember something about setting files via chmod 766. Is that info correct?
  • What are the odds that
    Migrate SugarCE to SuiteCRM >>SugarCE Migration 6.x to Suite 7.6.6. Size : 40.76 mb Format : ZIP
    Can cover my old version. Does 6.x really mean 6.anything?
  • my plan is to upgrade from SugarCRM 6.2.1 to SuiteCRM 7.6.6 (on test CentOS 5 box), and then create a backup/export to a test Ubuntu server, and then upgrade SuiteCRM to the current release; and finally backup/export to the production server; is this the correct path?

SPECS

Old Server

  • SugarCE Version 6.2.1 (Build 6405)
  • Centos 5-2.el5 2.6.18-92.el5
  • PHP Version 5.2.5
  • /opt/sugarcrm-5.1.0/php/etc/php.ini
  • /bitrock/sugarcrm2/build/output/php/lib

New Server

  • Ubuntu 18.0.4.2
  • PHP 7.2
  • everything lives in /var/www/suitecrm

first of all it would be hard as you coming from 6.2.
for upgrade better all permission must have on 777.

Ha, so 6.x is not 6.anything?
I believe I can get Sugar CE up to 6.5. So, I’ll test that, then try the upgrade on the test platform (Sugar 6.5 to Suite 7.6)
Thanks!

I was able to go from 6.2 to 6.3 successfully. From there I upgraded 6.3 to 6.4.6 The app kicked me out so I rebooted the (test/cloned) server. The app seems to be working but when I try the next upgrade it seems to hang then a ‘connection reset’ window appears. Is there some odd thing I need to upgrade? For example PHP from v5 to something slightly newer but release oriented (i.e. NOT 7.2 yet).

I’ve been searching for the 6.3>6.4 upgrade fix. I did find this on SugarCRM’s forums. This person was having the exact same issue as I am. the upgrade starts then seems to fail.


https://community.sugarcrm.com/thread/20585

Resolved. I copied off all of the files in the /cache/ folder and restored them, hitting the folders with a 0755 and the files with 0644 permissions. Then the upgrader completed, and said all was well. And it all worked.

I recognize this is a Linux question, but any idea what he means?

There is a /var/cache that I tried applying 777 rights to. Mind you this is a test box so I’m more concerned with the migration process than security. I also reviewed the files that were being copied during the upgrade, there are a dozen or so files with cache in their name, I don’t believe that’s what he as referring to and there was no ‘cache’ folder in the file copy list.

Also, after 777 on /var/cache, during the 6.3> 6.4 upgrade I get a pop-up from Firefox asking what it wants to do with index.php (i.e. how to open it). If I close that out a window shows saying ‘Upgrade scripts in progress’ but that sits there endlessly (45+mins right now) with nothing happening (CPU or memory wise).

In my scenario I believe the ‘cache’ is /opt/sugarcrm-5.1.0/htdocs/sugarcrm/cache

  1. My next test was to change /opt/sugarcrm-5.1.0/php/etc/php.ini to:
    max_execution_time=6000
    post_max_size=80M
    upload_max_filesize=80M
    max_input_time=6000
    memory_limit=256M
  2. reboot, you could restart apache
    3.login as admin and run a Quick Repair and Rebuild option in Sugar
  3. uploaded and installed 6.3-to-6.4.5 (not the 6.4.6)
  4. same question on index.php, figuring it was dead again I closed windows and rebooted
  5. when I logged in actually shows 6.4.5 as running
  6. login as admin and run a Quick Repair and Rebuild option in Sugar
    8: but f I try to upgrade from that point (goal being 6.5 so I can then migrate to SuiteCRM), again I get the index.php question but the Upgrade Wizard does not start

It does make me wonder if the current/installed PHP needs to be updated.

So as not to lose track of the big picture and wind up chasing red herrings…

My goal is to get my SugarCRM 6.2.1 data to SuiteCRM. Are there other better ideas?

  1. mysqldump from old to new?
  2. connect to the old system from the new system and import data?
  3. any idea on the minimum Sugar 6.x before I can import to Suite
  4. other ideas?

A few bits of advice…

  • don’t apply permissions randomly. It’s an exact science. Most of the times the issue is ownership (chown), not permissions. You need to be 100% sure which user your web server is using to run, and use that for the chown. Then apply the standard permissions. Remember to look also in config.php (default_permissions).

  • for PHP version compatibility, on SuiteCRM, keep an eye on this https://docs.suitecrm.com/admin/compatibility-matrix/ . I am sure there is something similar for SugarCRM - you can’t fail here, it won’t work. The same goes for MySQL versions.

  • I agree with the strategy of going up to 6.5, then upgrading SuiteCRM. You really need to use the upgrader scripts, not mysqldump. You can only use the dumps for migrations (from version X to the same version X on a different server), not upgrades.

  • the issue with index.php sounds like a web server config issue. It is not serving PHP by executing it, but by sending the file to the browser. May be related to MIME types of files, or .htaccess, or… ?

EDIT:

  • I also recommend getting away from Bitnami at some point, into straight Ubuntu, it makes upgrading the stack much easier