Close (or maybe you are saying this, but just in case)...you don't set a unique MiNT area-id for each AP, you setup a new unique MiNT area-id for each new building/RFDomain you want *by* creating a new AP Profile for each of those new building/RFDomains and then assigning the unique MiNT area-id as part of the new AP Profiles.
Regarding the controller itself - You should be okay with leaving the controller in whatever RFDomain it's currently in. Certainly, if you are going to leave some subset of APs functioning the original way (as they are now), you need to keep the controller populated within the same RFDomain as those APs.
*IF* you are planning on converting ALL of the APs so that they are all populated into new RFDomains, then standard practice for NOC style deployments (which this would then start to look like) would be to create a new RFDomain JUST FOR the controller cluster itself (no APs in it).
- No MiNT area-id configuration changes on the controller Profile are needed. The controller will still *see* all of the various MiNT packets...but in its default configuration, the controller will ignore the MiNT area-id value in those packets and will continue to interact with all of them. *IF* you DID specify a MiNT area ID on the controller though, it would then only interact with that SINGLE group of APs that are using that same area-id. Not good! Don't do that! 🙂
The area-ID's shouldn't affect the tunneled traffic, nor the L2TPv3 traffic.
If you are still considering doing this though, it needs to be well thought out and carefully planned. If you make a configuration mistake somewhere, you can/will cause wireless network disruption. I'd suggest opening a GTAC case and explaining what you want to accomplish...and if they're in agreement with this strategy, they can help walk you through the changes to make sure it's done correctly.