Yes, you should be able to; make sure to set the version in your web.config back to 6.1.1 and make sure that the umbracoMigrations table does not have version 7.4.3 in it (but that table doesn't exist on 6.1.1 so that should not be a problem).

For a more detailed look into how upgrades work, give the first half of this blog post a read: https://cultiv.nl/blog/how-to-diagnose-umbraco-upgrade-problems.

Whoops, wrong article, I meant to link to the one about migrations, although if you do have trouble upgrading, that post is also a good read:

https://cultiv.nl/blog/using-umbraco-migrations-to-deploy-changes/

It is not clear to me exactly what you are doing, but I don't think you need to tinker with the umbracoMigrations table.

If you are taking what you have and replacing your prod DB, the migrations are already done and you are all set.

If you are taking the code you have and running it against your prod DB, the migrations will automatically run and you are all set.

Thanks for the replies, I didn't see them till just now, I thought I was signed up for email alerts.

Devin

Nicholas,

I have a backup/copy of my DB as of a week ago, I used it in my trial run to see how the upgrade would go. As I approach a stable environment, and want to actually push U7 to production, I need to get an updated copy of the DB that can be migrated to be U7 friendly. In other words, I need to backup prod DB again and then run the migration then push the new website and new DB to replace the old DB and old website.

Make Sense? Devin

Makes sense now. The latest versions of Umbraco store all the migration info in the database. You should be OK if you backup your prod DB, let the migration run locally, then restore the prod DB back to production (along with the website files).

Although I'm not entirely sure why you would take such an approach, the site would be offline less time if you just push the files to live and then let the upgrade installer do it's work to upgrade your database.

FYI: we might in the future run code that for instance updates caches on disk, so you would miss out on that upgrade step in the live environment. This doesn't apply right now but keep in mind that in the future it might be required that you run the upgrade installer on each environment to make sure all your environments are in a consistent state.

Well more importantly, what would happen if the migration failed, I'd be dead in the water.

I don't get your second statement, are you saying there will be a portion of the upgrade that makes changes that needs to be run on production?

Devin

I often do what you are describing (backup prod, upgrade locally, restore prod) to be sure nothing goes wrong.

An alternative I sometimes do with lower traffic and lower risk sites is backup the database first, perform the upgrade (against the live database), then if anything goes wrong (uncommon) restore the old database backup from before the upgrade. I usually do that when installing plugins though (i.e., I'm usually on the safer side for Umbraco upgrades).

note:

we might in the future

Well ultimately my deployment for this will consist of something like, pushing to staging, swapping a copy of a fresh prod db in running, the upgrade, and swapping staging and prod

Devin

Just one more thing I'd like to add, the above method of updating the connection string and changing umbracoConfigurationStatus value to the previous version works. Just don't forget to make sure your umbraco user in sql has the db_owner role.

Devin

is working on a reply...