03.11 Legacy Transaction Migration

Status: draft for discussion

1. Goal

After merchant moves to the new system, historical transactions from the old Back Office need to be migrated to the new one.

2. Approach

Migration is done gradually: one payment method inside a brand at a time.

Migration is started by a platform user.

Only historical transactions are migrated.

Migrated transactions:

• are read-only;
• are visually marked as legacy.

3. What Is Needed for Migration

For migration, it must be clear:

• which merchant/method in the old system the transactions are migrated from;
• which merchant, brand, and payment method in the new system they are migrated to.

The exact migration tool and mapping are proposed by the development team.

4. Transition

Merchant starts using the new flow within agreed timelines.

The old system remains active while merchant uses the old flow.

5. Migration Result

After migration, the product should show:

• how many transactions were migrated;
• how many were skipped as duplicates;
• how many failed to migrate;
• where failed rows can be reviewed;
• which merchant, brand, and payment method received the migrated transactions.

Migrated transactions must not trigger new provider processing or new merchant webhooks.

They are historical records for viewing and investigation.

6. Legacy Visibility

Migrated transactions must be clearly marked as legacy in transaction list and transaction details.

Users should be able to filter legacy transactions.

Legacy transactions are read-only.