@nicksintros
I believe that this issue is related to the GUID on the IAP.
Essentially, if you have a single swarm (lets assume 10 IAP's) then remove 5 of these to create a new swarm, if you did not factory default the first IAP connected, before all subsequent IAP's were connected into the new swarm, it will retain its original GUID that it received from the original single swarm.
As such, when discovered in Airwave, it will recognise this 'unique' GUID and associate all AP's with this GUID to a single folder.
This will not impact your on-site wireless (assuming that they are in different Layer 2 domains) and there will be no impact to the user experience. The issue is that you will not be able to effectively manage the two separate deployments.
The easiest way around this is to factory default one of your swarms, but note - any resolution to this issue will require a reboot of one of your swarms - therefore an impact to service for the duration of the fix
If you have easy site access to one of your swarms, I would suggest that you turn off all the IAP's in one of the swarms only - with exception of the VC. You then have the option of either copying, editing and pushing this config back to the VC IAP or factory default - If site access is easy, I would suggest factory default of this VC device. Once rebooted, rebuild your configuration of this VC ( as prior to factory default) and then re-enable the remainder of the IAP's swarm.
Following this factory reset, a new GUID will be generated for this VC device and subsequently pushed out to all the other IAP's joining this swarm.
You will then be able to edit / correct the issue within Airwave as necessary.
Thanks,
Jason