Recently I had to step through the code which handles the check for an upgraded core because I library I wrote was not working as expected after the upgrade (this is a command line tool I wrote to administer the site). The logic which points to the upgraded core package is pretty airtight. I don't think you need to worry about leaky modules.

The upgrade process will modify your config/site.php with a new global, which is checked in concrete/dispatcher.php. If an upgrade module is present, it will dispatch through the updated core, and then call exit(), terminating the process after the upgrade core has rendered the response. The updated dispatcher will still look for overrides and installed packages relative to your BASE_DIR, which hasn't changed. So basically there is no possibility of what you are worried about happening.

A reason to overwrite the core manually (aside from having tools that won't work otherwise, as I did), might be if you have your website under source revision control. Otherwise you will end up checking in multiple cores. This can be accomplished by shuffling some files around and manually patching your site config.

If you have a major installation of concrete5 with lots of overrides, packages, and themes, I would be more worried about those breaking in the upgrade process. You'll want to test the upgrade process on a staging server (configured to talk to a copy of your live database, not the real thing).

As always, be sure to backup your database each time you upgrade.

Thanks, I appreciate the response. Most of the sites are pretty simple, so I'll probably back each one up and then go through C5's upgrade process. But, if the need to install a fresh copy comes up, do you know if there is a better way to move content, other than manually?

Yes, it's possible, although a little involved. If by content you mean the database driven site structure (pages, paths, Area and Block content), you can simply configure your "pure" installation with the same database credentials as your upgraded installation.

For the custom files which make up your site (File Manager files, themes, packages, and any overrides and .htaccess files you've written), you have at least two approaches:

1) Copy those files into your new installation. Off the top of my head, the directories you want to grab for sure are: files, packages, themes.
2) Update the configuration values which tell concrete5 where to look for each of those things. This should be avoided unless you can't move the files for some reason.

As Xaritas says, there shouldn't be a danger of cross wiring. That only happens if for some reason the upgrade fails part way through. Once an upgrade is complete and fully tested, you can move the code from the upgrades folder over the previous core (with an associated edit to config/site).

Always do a full backup before upgrading (database and files). If the site is complex, you can then use the backup to make a clone and practice the upgrade on the clone before doing it on the live site.
(its one of the reasons I wrote Backup voodoo)

It is also often safest to swap to a default theme during the upgrade, then swap back again afterwards. That will eliminate any theme related issues from the process.

You can export content into a starter xml file, then use that to create a new site. I have never done it. I have no idea how thorough it is.

Awesome, thanks a lot to both of you. Very helpful!

This is still my preferred way to upgrade a site.

http://adamjohnsondesign.com/blog/upgrade-concrete5-with-minimal-do...

Yep, that is basically the fiddling with directories and config files I mentioned. Nice write up. One thing to note is that if you go to the update page through the Dashboard, if you click download the system will download and unzip the new version for you, placing it in (if my memory is correct), files/updates.

I hate having the new core in the 'updates' folder for several reasons but mainly troubleshooting. My mouse gets worn out clicking through all the levels to get to the proper core files. I like a consistent path to the files and when you replace the old core with the new core, the paths all remain the same as they were before. I leave the old concrete folder in place for a while and then delete it when I'm sue I wonlt have to flip back to the old version. Sometimes it's nice to have the old version there just to see what has changed.

Right. I meant that the "download" function will select the correct version of core for you and extract it into the files directory. You can then manually move and apply the upgrade in accordance with the rest of the steps. Aside from removing a few manual steps, this is really nice because Concrete5 selects the correct version for your core based on its own dependency compatibility graph. This might happen in case you fall behind, for example l had a 5.5.1 site, and it fetched 5.5.2 for me first—I already happened to know that I couldn't upgrade directly to 5.6 but I could have wasted a lot of time if I had selected the wrong version manually.

Anyway, a minor point if you already know what you are doing but possibly helpful to the next random person looking at this thread.