Sounds like you're using CDR replication, and you are using the APP detection when creating the pair to replicate the SQL database? Are you trying an out-of-band sync or just a straight over the wan copy when starting?
Here comes my vent for the CDR our of-band-sync with exchange...prepare yourself. First, I would love your 16GB db vs the 200GB db exchange server with 50gb + logs I'm trying to replicate and the 24 regions the same situation. V8 SP5 CDR, I went round and round with support on the best method for trying to replicate this data over a wan. After numerous failed attempts with CV failing on itself and trying to re-replicate the entire edb file. Only one method seemed plausible after speaking with Cliff from the replication team. CV fails because of two reasons on the out of band sync. Either 1) USN was not marked properly prior to backing the data up and moving it to destination or 2)FLR change journal has already rolled itself over in the commserv database and CV can't recover. (The FLR rolling typically occurs when there is to much time between getting the data to destination and starting the pair. Come to find out there is also a way support can flag FLR and reset it after syncing the data. Wish I knew this prior to the other 10 failed attempts and prior to us upgrading to V9 SP1a which is suppose to solve all the problems by checking itself via the gui. Well in a sense V9 does correct it. Except on V9 in our environment being this large it takes the GUI out of band option 3 days to finally begin replicating, which by this time either source or destination is already flooded with 20+ GB of cv rep logs while it was busy checking itself and this puts itself so far behind that it never can catch up across the wan. Which leads me to another support call tomorrow to see if there is a method in v9 sp1a to perform a successful out of band sync without it taking 3 days to try itself and causing itself to get behind and never able to sync up. I'm sorry, we can't afford 2 weeks of no CRP's occurring while an out-of-band sync tries to occur. Maybe there is a way to out-of-band sync the rep logs...really...come on.
Not sure if my vent above made sense, but to truely answer your question. You're probably failing because CDR thinks the destination does not match the source and therefore is attempting to re-replicate your entire DB. Again this is caused by either the USN not being set properly before moving the data or FLR rolling to quickly in the commserv database and not being flagged and reset prior to starting the pair. The CDR.log will tell you exactly why if you just tail it on source. Another common cause is the setting on the CDR Agent. It will stop/fail itself if source or destination hits a certain threshold of free space on the cv logs directory. This is configurable as well as where the logs are placed on both source and destination.
I wish you luck, if you find a workable out of band sync method please let me know. Still looking for that magic answer that I'm sure someone knows. Cliff in Replication support has been the most help. Knowledgable guy. Hopefully I can reach him tomorrow. This environment being setup for replication keeps getting pushed and pushed because one thing after another...sigh.