Verify 7.x-2.x -to- 7.x-3.x upgrade path, mark 7.x-2.x as unsupported

Thank you, I will work on this per your guidelines and revert any closed issues that are feature requests.

After sorting through all the issues in the 7.x queue, I understand why a 7.x-2.x release has been kept available up through now -- some features that worked in 7.x-2.x were broken in the first 7.x-3.x release. Users who have remained with 2.x made the decision to do so about 5 years ago when the switch to 3.x failed to meet their needs.

Is an upgrade path necessary for this module? I read somewhere that the recommended procedure for version upgrades is to uninstall the current module before installing the new one, though most users take a shortcut and just delete the folder and upload a new one, presumably keeping old custom settings intact. Rather than spending time ensuring an upgrade path, perhaps we could include documentation to instruct users to do the following:

1. Make note of any custom settings in 2.x
2. Deactivate the 2.x module and go through the formal uninstall procedure
3. Install 3.x and then manually re-configure any custom settings

The settings on Backup and Migrate aren't that extensive, so it seems to me this would be a faster solution for the few remaining users of 2.x than spending time working on an upgrade path. Drupal 8 is now the "go-to" version according to a business survey quoted by Dries at DrupalCon Vienna in September 2017, so it's possible that many of the users we think are still depending on 2.x have moved on to Drupal 8 altogether. The users who want 2.x still have it, so could we just remove it from the Backup and Migrate home page and list the above instructions as a fast solution to deprecating 2.x?

That's great if you can find time to provide an update script. I didn't realize so many users were still on 2.x and wonder if the issues have been fixed with 3.2. Several issues filed indicated people upgraded to 3.0 and then went back down to 2.x around 5 years ago.

I've felt the reason 8.x Backup and Migrate has had such a poor adoption rate is because it wasn't even functional until April of this year and up through now has been listed as unusable on the home page. In the time between the release of D8 and now we have lost potential users to the alternate Backup Database module. It will be interesting to see how fast the 8.x user base grows once Backup and Migrate has a stable release. For me this module has been so important it was like an "upgrade blocker" to migrating my main site from D7 to D8.

There have even been recent issues, such as update_7303 breaking. That's kept me on 2.8.

@NancyDru did you try this method for upgrading since we don't have an upgrade path written yet?

So it seems like the status for "path of least resistance" is to disable + uninstall the 2.x version of this module before upgrading, and then install 3.x "as new" after the upgrade.

I have used the 2.8-dev version of this module on several sites for long time because of a bug in the 3.x version which caused it to not store the tables exception list (as the 2.8-dev version does). But that bug was just fixed in 3.x, so now we can move on :-) (ref. https://www.drupal.org/node/2290707 )

Yes, I did and it got past that. However, I still experience #2921980: Unable to restore from file because a file can't be restored to this database. which leaves me dead in the water.

@NancyDru so do I understand correctly that you have upgraded from Backup and Migrate 7.x-2.x to 7.x-3.x and now you are trying to restore a backup made from 2.x through the 3.x interface for a local dev environment?

Is it possible that a production copy of the site still exists and you can make a new backup from 3.x and restore to your local environment? I'm not sure if an upgrade path would fix the problem you're experiencing. Any other insight from other users is welcome.

I would like to get to 7.x-3 from 7.x-2.8. We have been on 7.x-2.8 since 2013. However, I'm not quite comfortable with doing that yet still since there has been issue discussions up to Nov 2017.

First thing, 7.x-2.8 shows in update status that it is secure and is the current version (green). Is it okay and safe to stay on this version?

So it seems like the status for "path of least resistance" is to disable + uninstall the 2.x version of this module before upgrading, and then install 3.x "as new" after the upgrade.

Second, Is the above quote the proper way to get to 7.x-3.5?

Uninstall 2.8, make sure db tables are gone, then do a clean install of 3.5?

@Crutch: That seemed the best way for me. I don't do anything fancy, so it was not a difficult task. But there is one more thing that's not been talked about much: I find with 7.x-3.x the receiving (importing) site needs to be at the same release as the site backing up. I don't know why that is; but I have encountered problems if they were not.

Well, since we have migrated most of our sites to Acquia and they list BU&M as undesirable, I just don't have any way to document that.

@crutch I am just curious if you're looking toward upgrading to D8 with your sites anytime soon? Development resources for Backup & Migrate are really limited right now, so a lot of the current work is going toward getting a stable D8 release. If you go straight from 7.x-2.x to the 8.x version, you may have fewer problems.

Not a lot of problems have really been reported for users switching from 7.x-2.x to 7.x-3.x, but as you see @NancyDru and a few others have run into several which are all still active and documented in the issues queue. Most people have moved successfully to 7.x-3.x, so if upgrading to D8 isn't an option for another year or more or if you're eager to get the improvements offered by the 7.x-3.x branch, then you should know that many users are successfully using and restoring from 7.x-3.x.