You should treat the failover to SQL Server 2019 as a one-way cutover and design your rollback strategy before that point rather than trying to revert the AG afterward. The safest approach is to keep SQL Server 2016 as primary during the upgrade, add the 2019 replicas, and run them in sync for a validation/burn-in period; only fail over once you’re confident. Right before the cutover, take full and log backups and verify restores this becomes your rollback point. If something goes wrong after failover, restore those backups back to the 2016 environment. If preserving post-upgrade data is critical, then instead of rollback you’ll need a side-by-side fallback plan (e.g., replication, ETL, or export/import). In short, don’t rely on AG mechanics for rollback use validated backups for fallback and delay the failover until you’re sure you won’t need to go back.