multi company is best when the verticals and processes are similar and there is a lot of scope for central services such as finance and purchasing. Ax 2012 makes it easier to enforce consistent data policies etc. Far more challenges come when there are multi-verticals and multi statutory localisations - in such cases central services are less feasible and the problems of conflicting code and upgrade fo multi companies is much greater. Each isv is unlikely to be compatible with the same Ax service pack, SQl pack etc at the same time, nor will they all be ready to migrate to a new release at the same time. The bigger the operation the grater the need for database emaiantenace such as defragmentaton and reindexing - the more companies and time zones, and audit dates involved the harder it is to plan system outages. Regional hubs with central financial consolidation may be a workable compromise. Consider the impact of a global payroll system- each country h=as an annual budget that chanes parolltaxes - what si the impact on your operations of taking your systen down each month to add the new code? What if one coutnry needs to upograde for staturoty reaosns and another couunty cannot because its isv module is not yet compatible at the new release? dotnet developments that are integrated make more sense- then you only have an interface upgrade to worry about. And those are just the easy points to cosndier!