Obviously, you have lots of flexibility in your approach to this migration project.
When you set up cascade replication - A to B, B to C, your first challenge is to insure you have accurately selected and verified replication from A to B. Any problem in the replication definition would be reflected in your B to C replication results. Once you have verified through sync checks and simulated role swaps that everything you need is included and accurate, then replication B to C would basically leverage cloning (RTVHACFGS) to create your final config and verify all replication results. When you successfully switch all your A to B replication groups, there is no need to restart replication B to A. Rather, change all the B to A groups to *STDBY to prevent your "pre-migration state" of your A server from being modified and would serve as your migration recovery instance. Once you have verified the B server state, B to C replication can be resumed with no configuration modification required. Once you are fully committed to the new role of server B, all B to A replication configuration groups can be removed from the cluster (along with the A node).
If you instead decided to use *HADR groups to aide in your migration effort, you would need to also create B to C replication groups separately and have them as *STDBY groups. Once you have completed your switchover to the new B server, you would remove the 3-node *HADR groups from the cluster leaving only the B to C replication definitions. You would then change them from *STDBY to *REPL, mark their starting position and start the replication groups. *HADR groups are great for an easy three node definition but are not useful once the requirement for three nodes is concluded. For that reason they might not be the best selection for a migration project unless there is an extended need for three nodes in the cluster after the activation of server B as Primary.
The last option I consider is three sets of replication groups. A to B, A to C, and create B to C as standby groups. Since you are verifying everything back to your A server with your sync checks, you would not be cascading any problems to your new C destination. On switch day there would be five steps to complete the switch.
- Switchover A to B (activates triggers, constraints, identity columns so the applications can be started on B)
- Change all A to B groups (now B to A) to *STDBY
- Change all A to C groups to *STDBY
- Change all B to C groups to *REPL, Mark position and start replication, Activate B server as Prod.
- After verification and commit, remove all *STDBY groups and the A node from the cluster.
As you can see the cascade replication option is the least complex on switch day however each approach to migration has its unique benefits. If replication may be configured and running for an extended time prior to the switchover (due to a lengthy testing schedule for example) I prefer the 'last option' as any challenges in replication are much easier to correct and verify (even though the switchover process has some additional steps to complete with this approach).