Слухи об ужасах многоверсионности, как обычно, сильно преувеличены.
Теперь по существу. Во-первых, для начала неплохо было бы провести расследование и выяснить, это всё же блокировки, или нет. Особой проблемы в этом не вижу, хоть это и прод.
Во-вторых здесь было начали правильно говорить, что некисло было бы для начала протестировать работу приложения, но потом всё скатилось в спор насчёт грязного чтения. Никакого грязного чтения при мультиверсионности, по крайней мере, по умолчанию не будет. Но логика работы всё же поменяется. Так, например, если некая транзакция начала менять некие данные, и не успела из закоммитить, то селект от другой транзакции будет ждать, пока отпустится блокировка, и прочитает актуальную версию данных. А в случае версионности вторая транзакция прочитает просто старую версию. И вот здесь надо решить, а это поведение оно вообще устраивает клиента и разработчиков? А не повлияет это каким-то образом на бизнес-логику софтины?
Ещё один момент это как эта хрень скажется на производительности и размерах tempdb. Тут вот не к ночи помянули Oracle. Так вот там на самом деле всё хорошо. Главное это следить, чтобы у UNDO сегмента было достаточно места, и хорошо бы его на быстрые диски положить. И чтобы оно параллельно ещё писалось/читалось. И в MS SQL, по наблюдениям, тоже всё неплохо. Надо только таким же образом следить за tempdb. Другое дело, что кривая апликуха может сожрать место в tempdb и нагрузить её, потому в архитектуре этот момент тоже должен учитываться.