While the second approach seems like the correct approach, since it replicates best what's in the current balance, this approach may not actually be feasible: there was a bug in - at least - 1.3 and 1.4 (which we recently fixed in 1.4) in the way payments are handled. The bug means that the base currency amount is correct and the foreign currency amount is wrong (for the payment line only). What's wrong is that the foreign currency and local currency amounts will be equal for the payment transaction, independent of the exchange rate. However, in the second approach, the revaluation will use the foreign currency amounts and use those to calculate the "correct" base currency amount.
It's easy to see how this approach fails to create a correct migrated balance.
The first approach however, is rather complex to code - with inherent bugs of its own - because there are multiple sources for fx transactions, each with their own special cases (AR, AP, receipts, payments, GL). Especially receipts and payments are complex due to the handling of FX gains and losses -- for which the *current* account setting may have changed, rendering it hard (if not impossible) to determine which account was/were the fx account(s).
Additionally, recalculating the amounts from the base amount and the rate could result in slightly different foreign currency amounts -- if only due to rounding.
If we don't want to go with approach (1), I also see a variant of (2) where we "fix" the data coming from the incorrect payments first and run a migration using that design after that.
Any help determining other options and approaches would be very much welcome!
Robust and Flexible. No vendor lock-in.