Why Migrate?

When you have 2 systems, old and new, there needs to be a strategy to switch over from one to the other.   Do you do a big bang; all on one day , or a pilot and parallel run  both systems. 

Both approaches have benefits and risks, and different stakeholders will score those benefits and risks differently. 

In DOKA SaaS we recommend a phased approach.  Many of the Contract types are relatively short lived and so can be allowed to expire naturally on the old system. 

Where there are long running contracts we provide some migration transactions.
These are modified 'opening' transactions that have the Fees, Documents, and General Ledger bookings disabled.  
The ethos behind this is that the contracts will have been opened on the old system and any fees , documents, and G/L were produced there.   Migration will bring them in to DOKA ready to continue the life cycle here.  

What can be migrated? 

We need to know the liability  (Party , Amount, end date) and any running regular commission fee (code , rate type , cadence).   

We have Migration contracts for the following scenarios:

GIMOPN - Guarantees (Standby LCs) 

LIMOPN - Import LC 

BRMDAV - Import LC - Document Set  (Contract needs to be in place first via LIMOPN) 

LEMOPN - Export LC 

BEMDAV - Export LC - Document Set  (Contract needs to be in place first via LEMOPN) 

BCMDAV - Import Collection 

BOMDAV - Export Collection 

PUMOPN - Payment undertaking 

RMMOPN - Reimbursement 

TRMOPN - Loans

Please see their relevant articles for file mappings. 

As an example let's look at a Guarantee (Standby LC). These typically run for many months, or years.  Therefore to wait for them to expire is not usually practical.   What state does it need to be in post -migration?

Therefore we have the GIMOPN transaction  which is very similar to the regular Guarantee opening transaction GITOPN, but with some additions and subtractions. 

We add in the ability to feed in a file with the values to map in to the screen fields.  This will allow automated upload of contracts .
See the article for detail of the file mappings it expects.

We subtract any outgoing messages and fees charged.  

The migration file is optional, you can just type in the values by hand.  But if you can extract the data from your old system, then you can automate the process. 

A Typical migration schedule

1. First decide what is to be migrated , and what can be left to expire on the old system . 
   Based on timeframes , most customers focus on the long running ones. e.g. Guarantees. 
2. Next, set up the necessary static data.  The Fees and Commissions that will be charged once this contract is migrated, need to be there in the new system. 
   And similarly , the Parties involved need to exist ( See article Upload of Address in DOKA SaaS on how to automate that) 
3. Now you can try a single contact, using the screen route ; type in the fields and Save it.  
   Before scaling up , you need to verify that the liability is correct and the Contract is ready to proceed in DOKA . e.g. any future commissions will generate the correct amount , to the correct party , on the correct date.  
4. Next is to automate this, at first by hand building a file and testing it maps everything as expected. 
   Then build the extraction scripts in your old system to create a file in the correct format. 
5. Finally you can use the Migration Task manager (MIGTSK) to run through large numbers of files. 
6. Experience shows that if you are  attempting this, then lots of testing and adjusting will be beneficial. 
   And if following a big bang approach then multiple dress rehearsals will be needed to iron out all anomalous data.  You want the upload to go through smoothly with no surprises.