Я бы сначала сделал миграцию как таковую, а потом бы уже подбирал ORMы под те ли иные нужды. Единственно - желательно архитектурно работу с данными убрать в некий data access layer (чтобы потом можно было, покрыв тестами, править только его, не сильно трогая код выше уровнями). Миграцию в данном случае тогда делать лучше на голом ADO.NET так как он позволяет делать с базой все что вам надо всеми перечисленными способами.
Когда переедете с PHP можно будет заняться уже ORMами. Для CRUD операций нормально подойдет EF. Для bulk update/insert-ов - возможно проще оставить ADO.NET (такие операции я бы еще сделал асинхронными для обработки в бекграунде с последующей нотификацией об окончании - через опрос или через push уведомления - скажем WebRTC). Для выборок со сложными запросами - убрать эти сложные запросы в хранимые процедуры и дергать их либо через EF либо через ADO.NET. На счет маппинга данных на объекты используемые выше уровня data access - использовать
AutoMapper. С его помощью можно смапить что-угодно на что угодно, главное не полениться и разобраться с возможностями его конфигурирования.
Единой ORM, которая хорошо охватит все перечисленные виды работы с данными и при этом будет оптимальной для всех, просто не может быть. У всех ORM в основе есть та или иная концепция - как надо работать с данными. Универсальные же системы - это когда все части работают одинаково (причем одинаково плохо обычно :) ).
