Вариантов несколько.
1. Полусамопальный. Только если между двумя серверами, и количество задействованных в репликации таблиц мало. Завести в таблице вспомогательное битовое поле, которое будет устанавливаться из триггера при любой модификации данных, а сбрасываться из JOB-а сразу после отработки агента snapshot-репликации. В snapshot-репликации настроить фильтр по данному полю. Объема бояться не нужно, поскольку происходит передача только тех записей, у которых установлен флаг того, что данная запись модифицирована с момента последней синхронизации. Нечто вроде атрибута "archive" для файлов. Можно идею несколько развить, чтобы устранить проблемы, которые могут возникнуть при модификации данных непосредственно во время работы snapshot-агента. Для этого вместо bit-поля нужно использовать поле DateTime (или SmallDateTime) и фильтр устанавливать по времени начала синхронизации, которое прописывается перед запуском синхронизации во вспомогательную таблицу. Ну, там уже додумаешь, если нужно.
2. Merge-репликация передает только последние версии записей автоматом.

>А что если добавить поле типа Timestamp?
А зачем? Если для того, чтобы узнать, изменилась ли запись со времени последней репликации, то нужно ее сравнивать с прежним значением этого поля. А для этого нужно по медленной линии просканировать значения данного поля на удаленном сервере для каждой записи (для того, чтобы выявить, какие записи модифицировались, а какие нет). Если размер записи небольшой, то сам процесс сканирования плюс последующая перекачка информации может обойтись дороже, чем snapshot-репликация.

Поля типа TimeStamp используются при репликации транзакций с целью выявления ошибок несогласованности транзакций. Например, запись с узла1 при snapshot-синхронизации передалась на узел2. После этого ее модифицировали на узле1, и репликацией транзакций передают новую версию на узел2. При этом сравниваются поля TimeStamp, которое было до модификации на узле1 с полем Timestamp на узле2. Если они НЕ совпадают, значит запись была модифицирована на подписчике уже после синхронизации, и не соответсвует ожидаемому состоянию. В таком состоянии передача изменения с узла1 может привести к нежелательному наложению двух модификаций на разных узлах друг на друга. Репликация транзакций выявляет подобные случаи и выдает сообщения об ошибках синхронизации.