Answers.Body: <p>I suspect everyone would have slightly different ways of approaching this according to their appetite for risk, but if you're anything like me, I originally didn't realise that re-running the upgrade for a second time with fresh data is actually extremely simple and fast - all you need to do is wire up the old DB with your newly upgraded site and do <code>./craft up</code>. In other words, assuming you have a deployment process that does that (or a combination of composer install + ./craft migrate/all) it's all handled for you when you deploy your upgraded version. The annoying part compared to pre-project-config days is that it will cause a few seconds of downtime while migrate/all happens, but it may be acceptable enough to do it without deliberately taking the site down.</p>
  <p>If those few seconds of downtime are unacceptable to the business, you'd need to find a way to keep the site up but conditionally disable any user-generated content such as registrations and form submissions, then call for an editorial content freeze before doing the upgrade on a separate environment and then switching seamlessly/instantly to that environment - typically with some kind of symlink. See for example: <a href="https://nystudio107.com/blog/executing-atomic-deployments" rel="nofollow noreferrer">https://nystudio107.com/blog/executing-atomic-deployments</a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-15T04:27:04.247Z
Answers.Text: Indeed, I didn't realize you could just do `./craft up` on an updated site with the older version of DB populated with the latest data.
  
  I already went with the second option you mentioned (freeze user-genereated and editorial content) but I'll have to test out the first option locally when I have to update to v.5 (coming out pretty soon it seems…)
  
  Thanks!
Answers.UserDisplayName: Yann
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-14T14:50:42.113Z
Answers.LastActivityDate: 2024-02-14T14:50:42.113Z
Answers.UserDisplayName: James Smith
Body: <p>I'm upgrading a site that has public registration from v3 to v4 (better late than never!) and it's going to take a few days to QA v4 locally to make sure everything works correctly… I'm wondering what's the best way to keep the new user accounts in sync.</p>
  <p>Is my only option to disable user registration while performing the upgrade? Or are the user tables self contain enough to update users independently once v4 is ready to go live? If so, how would I go about it?</p>
  <p>Any pointer in the right direction much appreciated!</p>
  
Tags: <users><registration><upgrades>
Title: What is your strategy for users accounts when upgrading Craft?
ThreadText: # What is your strategy for users accounts when upgrading Craft?
  
  (Asked by: username_0 on 2024-02-13)
  
  I'm upgrading a site that has public registration from v3 to v4 (better late than never!) and it's going to take a few days to QA v4 locally to make sure everything works correctly… I'm wondering what's the best way to keep the new user accounts in sync.
  
  Is my only option to disable user registration while performing the upgrade? Or are the user tables self contain enough to update users independently once v4 is ready to go live? If so, how would I go about it?
  
  Any pointer in the right direction much appreciated!
  
  **Tags:** users, registration, upgrades
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2024-02-14. Score: 1 | Accepted answer
  
  I suspect everyone would have slightly different ways of approaching this according to their appetite for risk, but if you're anything like me, I originally didn't realise that re-running the upgrade for a second time with fresh data is actually extremely simple and fast - all you need to do is wire up the old DB with your newly upgraded site and do `./craft up`. In other words, assuming you have a deployment process that does that (or a combination of composer install + ./craft migrate/all) it's all handled for you when you deploy your upgraded version. The annoying part compared to pre-project-config days is that it will cause a few seconds of downtime while migrate/all happens, but it may be acceptable enough to do it without deliberately taking the site down.
  
  If those few seconds of downtime are unacceptable to the business, you'd need to find a way to keep the site up but conditionally disable any user-generated content such as registrations and form submissions, then call for an editorial content freeze before doing the upgrade on a separate environment and then switching seamlessly/instantly to that environment - typically with some kind of symlink. See for example: <https://nystudio107.com/blog/executing-atomic-deployments>
  
  > **Comments:**
  > **username_0**: Indeed, I didn't realize you could just do `./craft up` on an updated site with the older version of DB populated with the latest data.  I already went with the second option you mentioned (freeze user-genereated and editorial content) but I'll have to test out the first option locally when I have to update to v.5 (coming out pretty soon it seems…)  Thanks!  
  
  ---
  
  