Why use the constraints at the destination? Integrity is enforced when the data is created, you only need to duplicate the data once it has been created. Since you are dropping the constraints to make the inserts I assume that the data is either not extremely dynamic or absolute data integrity isn't important within the scale of the intervals between the job runs.
If your data architecture was designed properly, the only issue you can have is old versions of existing records (which should be good enough for most reporting or analytics) and not have references that are just entirely wrong.
I'd be extremely leery of dropping and recreating the constraints regularly. If you need to maintain the constraints, I would write the job so it never violates key constraints, copying primary keys first, foreign keys last.