Hi Udo. Here is my personal opinion on the matter.
I always cringe a little bit when talking NetCentric vs AppCentric because we (Cisco) did not do a very good job articulating what it means from the very beginning. This is to say we made it sound a whole lot more complicated than I think it really is.
In my mind, Net vs App are really just two ways to describe how you prefer to group and organize your EPGs. That's it. They are both valid approaches, and in fact, you can use both in tandem across your tenants.
The analogy I use is to imagine a filing cabinet with three drawers. In each drawer you might choose to organize things alphabetically or numerically. Each drawer can use a different system. The result is the same in that you have organized things in a way you both prefer and understand. What we failed to explain well is that by giving them names like "network centric" we were only trying to give a hint that one way of organization tries to mimic your legacy understanding of vlans and subnets, versus organizing by app tiers that need to talk to each other.
So, what most people thing of as "net-centric" is one BD maps to one VLAN in one EPG. App centric is only different in that you can have many encaps (note my change in terms, but I mostly mean VLANs) mapping to a BD via multiple EPGs. That sounded kinda confusing. Put another way, in App-centric, you would naturally have more than one EPG mapping to the same BD. The EPG is what matters most because that is where you apply policy for endpoints.
So getting to your design. I will caveat that I don't have all the details of your setup, but I will try to give you my opinion.
First question: Do you absolutely require that each tenant has its own VRF?
Let me qualify that. ACI has no issue with lots of VRFs and we can do route leaking all day long. However, I often find people think of VRFs as a tool to segment things. It is a large hammer of a tool in that case, when other tools may be more suitable. IMO, multiple VRFs are usually most useful when you have overlapping subnets you need to address. Using VRFs for quick and dirty segmentation is not that way to go, IMO. I say that because it means you will now always have to configure and track route leaking and be sure you know what you have leaking at any given time. It is operational overhead that you might not actually want. I usually challenge customers to justify why they think they need many VRFs. In 90% of the cases, they realize they don't.
If you can put all your tenants in one VRF, that is going to make your migration that much easier. It would mean you would only have to create new EPGs under existing BDs that organize and apply policy to your app tiers. Migration could be as easy as moving the EPs to the new EPG when you are ready, and still allow communication to "legacy EPGs" via contracts where you wanted. No need to change IP addresses/gateways on the hosts. You would not have to worry about hair-pinning in and out to reach the legacy stuff outside. You would not have to worry about route leaking or overlapping subnets. Less is more, IMO.
This is just one man's opinion and I don't speak for Cisco, but you might re-think your approach to see if you can simplify things much like the examples I gave above. I also understand that I have oversimplified things to try and highlight general concepts. Your environment will undoubtedly have complexities I am unaware of that you will need to think around. Hope that helps.
