That is indeed a horrible situation. I can think of a couple of strategies depending on how many spokes you have. I would use this method if you have less than 30 spokes - and assuming you need the spokes to all be able to talk to each other (if this requirement does not exist then things get simple). This is how I would handle it: Create newOrg and place the new devices and licenses into it. Put an MX at HQ that belongs to newOrg into VPN concentrator mode. Initially, on the new MX in newOrg create a static route for every spoke in OldOrg, pointing to the LAN IP of the MX in OldOrg, and publish all of those static routes into AutoVPN. When you move a spoke from oldOrg to newOrg, move the static route from the MX in newOrg to the MX in oldOrg (except the next hop will now be the LAN IP of the MX in newOrg). Make sure you publish the static route in AutoVPN. This will ensure all spokes can always talk to each other. You can do this at a larger scale by publishing supernets instead. You won't be able to get conflicting subnets, because at all times both newOrg and oldOrg will know about every route in the combined systems. This approach will allow you to do a slow migration.
... View more
