No, you have to plan the downtime for this activity.
But you can minimize the duration of the downtime.
Some steps before migration itself:
1. Make sure newly created bond can see Partner's MAC and LACP is working fine.
2. Make sure the needed VLANs (if used) are correctly created/tagged on the relevant switch(s).
3. Have all the config and steps prepared in advance (including rollback situation)
4. Perform backup and snapshot on both cluster members
One of the scenario during migration itself:
1. Change the topology information in SmartConsole (name of interface) and push the policy. The firewall will not change the VIP since the IPs are assigned to the current interface.
2. Bring standby member down (clusterXL_admin down)
3. On down member, change the IP config over CLI (remove IP from single interface and assign to the bond)
4. Push the policy once again
5. Down member should have VIP assigned to the bond, while active member on single current interface
6. Cluster_XL admin up on down member. That may cause the failover to the node which already has info about bond interface.
7. If the member is still down, try to shutdown some interface on active node or perform cpstop on active node in order to force the failover
8. Perform IP config change on former active node