You could look at log shipping to keep the new 2016 instances up to date well ahead of your upgrade. If you log ship from the current primary to all four new replicas then the cutover and sync is much quicker.
Assuming you're creating a second 2016 AG (and not joining the 2016 instances to the 2012 AG) then at the point of cutover:
- Take a log backup on 2012 Primary and restore on 2016 servers with norecovery
- Recover DB on 2016 primary
- Add DB to AG on 2016 primary and take a log backup
- Restore log backup on 2016 secondaries and join to AG
- Remove listener from 2012 AG
- Add listener to 2016 AG.
If you run into issues post-upgrade and need to revert to 2012, simply remove the listener from 2016 AG an add it back to 2012 AG. The 2012 AG will have carried on like normal and will continue working. The caveat here is that once 2016 is live (after any post-upgrade testing) you won't be able to rollback to 2012 without data loss.
If you're adding 2016 to 2012 AG then log shipping can still be used, but the cutover process is much more complicated as you have to replace the 2012 replicas in a piecemeal fashion as 2012 only allows 4 replicas. Rollback is also more complicated and may leave you without HADR after rolling back until you resynchronise the 2012 replicas.
You need to define this process thoroughly and run through the whole process in a lower environment multiple times to make sure you've got everything aligned and working.