NServiceBus doesn’t provide strict message order guarantees. This is because most transport already don’t support this and additionally, some features like recoverability, delayed delivery and others work the way that a message is reordered (e.g. retried at a later point in time). As you already pointed out, it’s basically impossible to build a reliable data replication mechanism based on those properties.
But more importantly, it’s not recommended to use messaging* as a synchronization mechanism to sync data. Syncing data is very brittle and a simple problem can desync your databases forever while you won’t notice it.
I’m aware that this might not be the answer you’re looking for, but here I go anyway: Have you considered approaches where you keep the data of your new and your legacy system separated instead of syncing those? Syncing data between two systems introduces a huge level of complexity (e.g. dealing with concurrent writes to the same data on both systems) which I’d avoid whenever possible. Messaging is an excellent tool to introduce new functionality via dedicated, autonomous services without rewriting the complete legacy system.
* there is another type of messaging which support strict order in messages which is often called event streaming, stream processing or similar. While these technologies also use asynchronous messages they work fundamentally different in regards to message types, message persistence and message consumption. But these systems can often be used for “log shipping” which can distribute database transaction logs reliably across consumers to create replicas. A typical example for this would be Kafka.