Three ways to upgrade Matomo with zero downtime or data loss

Three ways to upgrade Matomo without losing data (this is for sites with more than 1M hits/month).
Two of these are described here
https://matomo.org/faq/how-to-update/faq_20844/


Option 1 -
Creating a copy/replica of the existing production environment with a test database
The steps for this would be as follows:

1. Create a replica/copy of your existing production server for Matomo
2. Update the config file to point to a testing/dev Matomo database
3. Update all plugins on this server
4. Update the database credentials to point to the production database
5. Update DNS records or Load balancer config to point to this new server
6. Run the core:update command to update the productions database

This option has the benefit of being able to update the codebase without directly making changes to the production environment, but doesn't allow for 1:1 planning for any potential issues with the production database.

Option 2 -
Creating a copy/replica of the existing production environment including the Matomo database
The steps for this would be as follows:

1. Create a replica/copy of your existing production server for Matomo
2. Create a copy of the production Matomo database
3. Update the config file to point to the copied Matomo database
4. Update all plugins on this server
5. Run the core:update command to update the copied production database
   (This is our opportunity to look for potential issues and find an accurate time to plan for the production update)
6. Once we've tested the update, we update the database details to point to the production database
7. We can then update the DNS records or load balancer config to point to the new server.
8. Run the core:update

This option has the benefit of updating the codebase without impacting the production environment, planning for any specific issues that might arise from updating the production database and have mitigation strategies for that. It also allows for an accurate estimate of the required maintenance window for the production database update.

This strategy does not allow for minimal downtime and tracking during the update would need to use either the Queued Tracking or Log Analytics method mentioned here: https://matomo.org/faq/how-to-update/faq_20844/

Option 3 -
Creating a copy/replica of the existing production environment including the Matomo database and migrating to this replicated setup once updated.
The steps for this would be similar to option 2 and are as follows:

1. Create a replica/copy of your existing production server for Matomo
2. Create a copy of the production Matomo database
3. Update the config file to point to the copied Matomo database
4. Update all plugins on this server
5. Run the core:update command to update the copied production database
6. Once we've tested the update and ensured that everything is working, we can then update the DNS records or load balancer config to point to the new server.
7. We backfill any tracking data that was sent to the old production instance since the replica was made

This strategy allows for the most amount of planning and doesn't require specific timeframes to complete the update. Since we can backfill the data as much as is necessary using the Matomo web server access logs (These need to be enabled in the web server configuration). The update can happen while the existing production database is running and the switch can be made once this replicated setup is fully updated and ready. The backfilling of tracking data can also be tested while running in parallel to the existing production setup to check for any potential discrepancy in the replayed tracking data.