Migrating to new Source and Target from current source

Hello. 

I have a customer that we are migrating to iCluster from iTera. We have access to their source system and have created a new source (To be source) system and target (to be target) on our servers. 
We were planning to migrate them by pointing the current source system to our two systems. Theirs will be called system A, our to be source is B, and our to be target is C. 

Original thought was to Point A to both B and C. Then we would roleswap or shutdown A, and then modify B to point to C and be done. But while setting up the groups, this did not seem to be the way to go. Using *HADR did not seem like it would work (the only way I saw to point to two different systems). 
We opened a ticket with support, and they suggested A to B, and B to C. But that also brings up questions about how to do the switchover and get B to be the new primary and leaving out A. 

Currently we do not have access to the iTera target, so we cannot use the preferred method of Old Source to new source, old target to new target method, which also brings about questions on how to switchover and point new source to new target. 

Any help is appreciated.

Hi Ed,

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.

1. Switchover A to B (activates triggers, constraints, identity columns so the applications can be started on B)
2. Change all A to B groups (now B to A) to *STDBY
3. Change all A to C groups to *STDBY
4. Change all B to C groups to *REPL, Mark position and start replication, Activate B server as Prod.
5. 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).