There are a number of procedures that can be used to migrate data from legacy systems to DOKA-NG. These can all be adapted to meet the needs of the specific project.

As long as there is one option to export static data such as addresses, accounts or limits in their defined structure from legacy systems, this data can be imported into DOKA-NG.

The idea of migrating contracts is to enable transactions that have been started in legacy systems to be transferred in precisely their current life-cycle status to the new system. With special transactions that add contracts, all data relevant to the contract can be captured and correspondingly saved. As long as the legacy allows the data to be exported on a contract basis, the data can be read during the migration and automatically transferred to DOKA-NG fields.

A number of aspects need to be taken into account when migrating data:

• Are key fields (e.g. address number) to be retained or converted to a new key?
• Are (externally known) contract references to be retained, or are new reference numbers to be assigned (save old reference separately and use externally, or send notification of change to all parties)?
• How are user codes in the old and new systems to be handled, and contracts assigned to users?
• Are obligation entries to be transferred, or booked out of the legacy system to be booked back in in DOKA-NG?
• Do static data banking structures match or is it necessary to instigate changes?
• Are all contracts (to one business sector, or to all sectors) to be migrated on a given date, or will you be working in both systems for a period of time (useful, for example, when it comes to monitoring limits)?

There are already a number of transaction that could be use to migrate. The procedures implemented here may also be used to transfer data from other legacy systems.

The issues and scenarios described below will be helpful in planning in-house migration procedures.

A possible scenario when transferring addresses and accounts from DOKA 4 is as follows:

• The data to be transferred is exported from DOKA 4 in the DOKA 4 dataset format, either completely or selectively, as required. Corresponding export programs are already available for this in DOKA 4.
• A table, AD4, is set up that maps all the fields from the DOKA 4 ADR address record
• A table, AK4, is set up that maps all the fields from the DOKA 4 AKT account record.
• If AIF fields have been defined in DOKA 4 for addresses or accounts and if the content of these fields is also to be transferred, an AIF table is set up that maps all the AIF fields required.
• Address data is imported in the AD4 table using the IMPAD4 transaction.
• Account data is imported in the AK4 table using the IMPAK4 transaction.
• AIF data (from an XML file) is imported in the AIF table.

After this, the DOKA 4 data is ready to be transferred to the DOKA-NG static data tables.

Transaction IMPAD5 is used to add party and address (PTY, PTA, ADR, PTM, OIT) details from the address data.

Transaction IMPAC5 is used to add account records (ACT, OIT) from the account data

Transaction IMPLIM is used to add limit records (LSB) from the account records

All the selections and conversions required can be carried out in these transactions. In addition, all the AIF data required can also be read.

Here, the following points can be taken into account:
DOKA 4 only recognizes addresses. References from one address to another can made using the 'Group' or 'Principal bank' fields.
DOKA-NG recognizes parties associated to a main and any number of additional addresses. Here, references to other parties can be stored using 'Head office' or 'Principal bank' fields.

The simple transfer of ONE address to ONE party with a single (main) address is, in a contextual sense, usually problematic, because it is not unusual for one party to have several addresses.
This is particularly relevant when adding/transferring accounts: in DOKA 4, for example, an account number can be stored under any number of addresses.
In DOKA-NG, an account number is associated to a party and can only be captured one single time (within an entity).
Here, a way must be found of merging addresses that belong to the same party.

When transferring data from the bank's own accounts, it is important to note that these are usually stored under the call number '0000000000' in DOKA 4, but have to be assigned to their own addresses in DOKA-NG. Where necessary, special rules for transferring nostro accounts may be required.

If call numbers assigned in DOKA 4 are stored in the DOKA-NG address data, it is possible to assign this data to the correct parties/address in a subsequent migration of contracts.

Samples of all the transactions and tables mentioned are available and have to be adapted to meet the needs of the specific project.

Other static data can be transferred in a similar manner - providing the transfer is at all feasible and meaningful as far as the structure and available content is concerned.