If this is feasible depends heavily on what 'similar' data means, and if the systems are sufficiently different, this can become arbitrary complex, and you may have to resdesign the existing systems for it. It is usually not sufficient to have business entities in both systems which can be mapped to each other in a 1:1 fashion - all kind of transactions involving these entities must be mapped as well.
Let us make an example: since we talking about CRMs, you surely have customer entities in both systems. First thing you have to ensure here are primary keys and unique indexes don't collide. If only one of the systems will forbid to use the same name twice, you can already run into trouble: if a customer c1 is added to system 1 and a different one c2 to system 2, but accidentally both have the same name, what will this mean to the syncing process when system 1 has a unique constraint on the name?
Maybe the customer in system 1 was entered earlier, so c1 "wins", but if c2 cannot be transfered to system 1 without manual intervention, maybe including a bunch of c2 related data which then cannot be transfered to system 1, your users probably won't be happy.
If the synching mechanism will try to "merge" both customers automatically, but in reality these are different companies, your users won't be happy either.
The syncing mechanism could also be allowed to resolve the issue by automatic renaming to keep c2 separate from c1 in system 1, but this needs a thorough analysis of how this renaming should take place and how the users can deal with such renamed customer records.
This problem can be overcome if you use surrogate IDs exclusively with different ID ranges for each system, and no other unique indexes. That is how DB replication (between system with equal schemas) is often implemented, but you are talking about existing systems - are you free to redesign them in that way?
Even if you solve this, what will happen if in system 1, there is extra data for each customer which will forbid deletion of it as soon as it is entered, and this extra data has no pendant in system 2? Now in system 2, someone is allowed to delete c1 (since there is no such related data), but in system 1 this deletion is not allowed. What will this mean to the syncing process?
This can be overcome by forbidding direct deletions for entities in system 2, at least after they were synchronized to system 1, which means you have to track the syncing state and model this into the system.
What this all means here is:
- it may be possible, but you have to design the replication / syncing deeply into the system.
Don't expect to bring a generic bidirectional synching mechanism just afterwards to two existing systems as a "separate, independent module", without heavily touching the existing design. Using the "unidirectional" approach, with one leading system, is an order of magnitude easier to realize and avoids most of those pain points.