There are two procedures in Db2 for z/OS that helps users to convert from PBG to PBR and move tables from multi-table table spaces to PBG. As a reference, the links are as follows.

1. Converting from PBG – PBR https://www.ibm.com/docs/en/db2-for-zos/13?topic=at-converting-tables-from-growth-based-range-based-partitions
2. Moving tables from multi-table table spaces to PBG https://www.ibm.com/docs/en/db2-for-zos/13?topic=ats-moving-tables-from-multi-table-table-spaces-partition-by-growth-table-spaces

If the user has Db2 Analytics Accelerator or Data Gate, replication enabled tables via Integrated Synchronization are impacted by these procedures if one or more replication enabled tables are touched. Users need to be aware of the possible replication outage for the affected tables.

In Procedure 1, there is a suggestion if user wants to change the number of partitions to a smaller number.  If the user wants to convert to the same number of partitions, DATA CAPTURE CHANGES setting can be kept as is. however, if the user wants to convert to a smaller number of partitions, setting DATA CAPTURE CHANGES NONE is suggested. After setting DATA CAPTURE CHANGES NONE, the log reader task of the replication will pass an alter log record that data capture changes are turned off. This will result in suspending tables from replication and set them into error state in the Accelerator or Data Gate. 

Anyway, changing from PBG (rows can be in ANY partition) to PBR (rows belong to a certain partition), replication (irrespective of DATA CAPTURE CHANGES setting) set the table into error and reload is required so that replication knows which partition each row belongs. So, a conversion PBG to PBR is a disruptive conversion with respect to replication and will require a full reload of the affected tables to resume replication.

In Procedure 2, this procedure does not mention about any DATA CAPTURE CHANGES but since the tables will go to new tablespaces during this operation, the user needs to reload them to the accelerator or Data Gate again. So, moving tables from multi-table table spaces to PBG is also a disruptive conversion with respect to replication and will require a full reload of the affected tables to resume replication.

In Summary, If the user uses the described procedures and tables in the affected tablespaces are enabled for Integrated Synchronization, then the tables will be suspended from replication during execution of the described procedures. The user must fully reload the tables to the Accelerator or Data Gate to resume replication.