Code First is not suitable for large scale applications. Large scale apps development turnaround is very huge.
Typically life cycle of your business app is like,
- Version 1 is in production
- Version 2 is in beta
- Version 3 is in active development
- Version 4 is in planning.
And there are other Cross Application communication bridges, some scheduled tasks, some third party integration, web services for some different communicating devices such as mobile etc.
Eventually Code First uses Entity Model's ObjectContext, Older EF generating EDMX and using ObjectContext with EntityObject was really sufficient for everything. You could easily customize text template to generate code. Detect Changes method is slower with ObjectContext implementation, but instead of generating proxy, EF team could have easily improved Detect Changes speed instead of reinventing code first.
Automated Migration sounds good in theory, but impossible in practice once you go live. It is only good for prototyping, developing some quick demos.
Code First Migration is not at all suitable in such system. Version 1 and Version 2 most likely talk to same database. Version 3 and Version 4 is usually staging and has different database.
Database First is practical approach, it is easy to compare and visualize and maintain SQL Scripts. DBAs can work with easily.
We created our own Text Templates to query and create EDMX and ObjectContext with little custom implementation that addresses performance issues. There are multiple applications with multiple versions communicating to same database without any problems.
To me, right clicking on .tt file and clicking "Run Custom Tool" is by far fastest and easiest step then writing classes, configuring and creating model.