Прежде всего - если CRM станет продуктом, который вы продаете, то, по всей видимости, создайте его - если он предназначен для внутреннего использования, я бы сказал, пусть кто-то другой выдержит боль при решении этих вопросов и просто купит CRM.
Кроме репликации на уровне базы данных, которая, на мой взгляд, недостаточна для решения всех проблем, вам действительно нужно «свернуть свою собственную».
Я пришел в команду, планировавшую некоторые CRM-подобные компоненты системы, и первоначально они планировали использовать репликацию базы данных, потому что это выглядело легко - до тех пор, пока вы не дойдете до разрешения конфликта.
В итоге мы перешли на использование идентификаторов GUID в качестве уникальных идентификаторов, поскольку это значительно упростило обработку новых записей, созданных пользователями - в противном случае вы получите эти неуклюжие схемы разделения числовых идентификаторов для каждой клиентской системы. Дорога в ад.
Ничто не помогает в разрешении конфликтов, когда между синхронизациями происходят изменения, это касается уровня приложения. База данных может получить список транзакций для воспроизведения от Боба, но если он отредактировал то же самое, что и Алиса - какую версию он должен использовать? временных отметок недостаточно, потому что, если Алиса заполняет ее, когда уходит и у нее есть ранняя временная метка, но Боб ждет, пока он обедает, и получает более позднюю временную метку.
Я бы действительно посоветовал прочитать все статьи / записи блога, которые вы можете о синхронизации и разрешении конфликтов - синхронизация проста с высоты 10 000 футов, где вы можете быть волнистыми, но это другая история, когда вы не работаете в грязи.