I asked my programmer to upgrade to your latest version of SuiteCRM. He said, he would rather not because all of your version upgrades are in the custom folder and that you are not upgrading the core. Is that correct?
I would say it’s the other way around, upgrades usually change more things in the core than in the custom folder. The custom folder is where our own stuff is, our specific customizations. The less it is messed with, the better.
There was only one update a few months ago that moved dozens of files from the custom folder to the core, basically everything related to the modules made by SalesAgility and other contributors. These were customizations in the SugarCRM days, but now they are part of the core product so they were moved.
I don’t think upgrades are any problem, but you should have proper backup measures (you should have them anyway, right?). I run SuiteCRM in a Virtual Machine, and I always take a snapshot before upgrading. That way I can always go back if anything goes wrong.
We have customized the software extensively to work with our website at http://www.mswoods.com. We collect leads daily and distribute them through custom round robin distribution system or a custom blast system to all agents at our company. If we upgrade, do we copy all of your programming in the custom folder and add it to our programming in the custom folder. or should we handle this a different way?
First of all, when you say “you” I think you mean SalesAgility, but I’m not affiliated with them. These are community forums, everybody can answer here. (The SalesAgility employees have a red username, because they are site administrators).
You should know (Google it if necessary) the difference between customizations that are upgrade-safe and customizations that aren’t.
Basically, if you did everything correctly, you shouldn’t have to worry about upgrades because they won’t touch your upgrade-safe customizations (stuff you add on the custom folder).
Sometimes people also do unsafe customizations in the core area. The trick here is to keep them as simple as possible, and to keep a list of all of them. After each upgrade, you would need to check and possibly re-apply each one. It depends on the files that were changed by each upgrade, whether they overwrite your changes or not.
If you don’t have a way to try an upgrade without great risks, then that’s the problem I would worry about first. Make sure you have actionable backups, move you setup to virtual machines, clone your server and try that on the clone, whatever. But you shouldn’t have to be insecure about your company business just in order to try a few new features in a software.
I hope this helps.
Thank you for the information you’ve provided. Sorry about confusing you with the company
I just spoke with my programmer again about this. He said,
“Everything is upgrade safe (with sugar). Every last bit of code I’ve written is safely tucked away in the “/custom/” directory like its supposed to be to keep Sugar upgrade safe. The problem is, SUITECRM doesn’t respect the custom directory like Sugar did. There is no upgrade-safe guaranteed in Suite.”
Is there something different about SuiteCRM from SugarCRM that would cause this?
That separation between core/custom has been around a LONG time from the SugarCRM days; and it hasn’t changed, essentially, in SuiteCRM. Every SuiteCRM developer knows this, so they are careful with where they place each change.
So what your developer is saying doesn’t sound correct to me, and it’s not my experience (I regularly upgrade and all my customizations are preserved).
But he might be right to some extent, he might have had a problem in the past. Sometimes these things aren’t 100% sure, things break. As I said above, the most likely culprit would have been that upgrade (7.5.1 if I’m not mistaken) where a lot of stuff was removed from the custom directory (but only stuff written by SalesAgility, their modules).
Which version are you on now, and to which version are you planning to upgrade? You can just go and check what is in the upgrade package.
My current version
Version 7.3.1
Sugar Version 6.5.20 (Build 1001)
The current version
SuiteCRM 7.6.4
I don’t see an upgrade version from 7.3.1, jeesh.
Yes, it’s a big upgrade, you might have to do it in 2 steps.
This might be a good time to upgrade Apache, MySql, PHP (see compatibility matrix here https://suitecrm.com/wiki/index.php/Compatibility_Matrix )
With so many changes to be done, I would also consider just installing a new SuiteCRM 7.6.4 server already with PHP 7 and moving your “custom” code over from your current server.
What kind of hosting do you have? Do you have SuiteCRM running inside a Virtual Machine?
I have a dedicated server: 16 cores, 8 solid state drvies and64GB RM that I use for msWoods.com and crm.mswoods.com and some other sites I own.
Well, I don’t know if you still need any help from me, but depending on your setup, virtualization, backup servers, basically your abilities to clone your setup, my only point is that it should be easy, and not risky, to just try the upgrades and see if they work well. You’re supposed to have several environments, one for development, one for testing, one for production (real-life business usage).
I do that in a much cheaper setup than yours, and it takes me 30 seconds to revert to a safe state in case anything starts to worry me. I’m never stressful about SuiteCRM upgrades, and I just do them a few weeks after they come out, and when I have the time to work on them.
This also has many advantages for disaster-recovery. I hate backups that make you go through a lot of administrative work to get things running. I like to be able to just fire up my backup VM and everything is exactly as it was.
I’ll assume you have all this worked out but if you still need any advice I can try to help. I wish more people were participating in this thread, though; hearing from more than one person usually makes for better judgments and solutions.
Thanks for the help. My programmer and I talked about it. We have decided to wait until the bug fixes of 7.7 are complete before upgrading. The last time we upgraded, it totally erased all of our programming in the custom folder.
msWoods,
Just to chime in here… I personally keep a list of all of my changes (custom or otherwise), and then use a php editor software (notepad++ or JetBrains) to compare the differences between the upgraded file and the file I already had.
I clone my install (I don’t have VM, so that means just setting up a new subdirectory with the files and a new database with the contents - takes about 20 minutes) and try the upgrade there first. I then do all of these comparisons, so when I do the production server, I know exactly which files will need updated, and in fact, I’ve already been able to prepare the merged changes into a file ready to upload. I test test test the cloned install too, before trying to upgrade the production server.
I would say it takes me about a day to do an upgrade… but that is partly because I don’t do it very often and have to remember the steps and think it through. It probably takes only about 2 hours on the actual production server once I’ve worked through it on the dev server… so the downtime is actually quite small.
sieberta