To migrate or not to migrate, that is the question: Whether 'tis nobler in the mind to suffer the slings and arrows of past setup sins and mistakes, or to take arms against that sea of troubles and by migrating end them.
Or not. If you were asking "Should I upgrade in place or migrate?" I'd have directed you to an older (and longer) answer I gave which, in short, says MIGRATE - ALWAYS MIGRATE!
But you didn't ask about an upgrade. You asked about an Availability Group. I commend you to that post on in-place vs migration upgrade decisions and contemplate where you are. If you are on a virtual and like the version of SQL you are on and only have to reconfigure "stuff" - I see no pressing reason to do a migration. You simply can add windows clustering, setup the AG feature, and start building your AG. You can use this as an excuse to cover for past sins because most config changes, etc. are "online" settings you can make as you go. On a VM you can play with your CPU config and RAM, etc.
If you need a new version of SQL Server or made some crucial installation mistake (hard to think of any, perhaps 64kB drive allocation size, but that's not the end of the world and you need new drives anyway), then sure install afresh and migrate. Or if you are on a physical, have the licensing budget, and can demonstrate the need for more cores, then you have no choice but to build new and migrate.
BUT! You are building an AG. You now have a magical THIRD OPTION. You could build your new server just the way you want it. You could add that as a node into your AG. You could build the AG with this instance participating as a replica in the AG with two instances you like the config and sizing of better. And then just failover to one of those and evict your current node and kick it goodbye. So you could use your AG to sail on over to the new hardware with minimal user frustration and look like a hero.
