Using federated, you can do data changes on the remote db, but the nickname cannot be in a trigger or cannot take part in a 2-phase transaction, ie, data change is allowed only on the remote table in the uow.
Coming to your problem, How soon do you want the old database to reflect the new one?
If you want to keep it as close as possible, then sql replication or q replication are the options. the former one is easy to setup and maintain.
If you want the 'replication' once a few hours or once a day, then triggers may be an option.
When using a trigger, instead of recording every event on a row in the audit table, ie , one row for insert, another row for an update etc, you can have one row for every changed row. ie, if you have only the final image of the row in the audit table. You can export the data from the new database and import using insert_update in the old db.
But if you have too many changes in the tables, your performance may suffer if using triggers.
HTH
Sathyaram