Windows->Oracle--> Windows  SQL (Database Migrate and SAP UPD)
AIX|DB2|DB6|Oracle-->  AIX/Sybase(Database Migrate and SAP UPD)
Linux(SUSE|RHEL|POWER LIN) ORACLE|DB2|SYB--> LINUX---HANA

DMO is used only when there is a change in database. Homogeneous Migration is not allowed.

DMO
The processing sequence is based on the shadow system functionality of SUM
1.The SUM creates the shadow repository on the traditional database until downtime phase, while in parallel the target database is being set up (such as client, schema).
2.The shadow repository is copied to the target database. Then the downtime starts.
3.After the migration of the application data (including data conversion), the update is finalized and the SAP system runs on the target database.
The Source database continues to run and it is not modified. It remains as a fallback for the Reset Option throughout the complete DMO procedure. 

Differentiate SUM vs DMO SUM

1. it checks for stack.xml file.Place this XML file in the Download Directory,so that the downloads such as patches,kernel are checked in the current path.

2.as the DMO changes the Target Database the Additional kernel files are required for Target DB

3.as the DMO Involves database change it requires migration key and DB client to connect to DB.Technically, SUM triggers the R3load to export and import the data. Further on, the shadow repository is created on the source database first and then migrated to the target database.

4.An easy fallback to the traditional database is possible, as long as the source database and the SUM directory (of the existing update) exist. Do not perform a reset in a productive environment after the end users started working on the new system based on the new database.

5.Password restrictions for SAP HANA database
Currently, the password restrictions for users on SAP HANA database are different to those of the SUM. Take that into consideration when creating users for the SAP HANA database. Hint: Start the password with a capital letter and use alphanumerical characters only.
_______________
Pre-Steps of Migration

1.Ensure that backup of the system is taken and it is recoverable State.
2.Clean the Temp Tables that are not required(WorkFlow Tables,ABAP Dumps,System Logs etc)
3.Document all the external Connections such as Point of Sales,BIO Metric Devices,Weigh Bridge machines etc..
4.Document all the Printers
5.Identify the larger tables for Table Splitting
6.Ensure that Custom Tables Defintions are taken by using a report SMIGR_CREATE_DDL.SQL
7.Ensure that a System Copy is performed to simulate the Test Migration. Iterate as many times as possible to get the exact Down Times of Export and Import.
8.Parallel Export and Import can be scheduled based on Available resources.
9.The Number of parallel Processes such as R3Load can be calculated as 1 or 2 Per CPU.
10.Table Splitting File should in the Format 
tablename>%<No.of splits> ex: (ACCTIT%50)
11.Update the Export and Import Tools such as R3load,R3ta,R3szchk,r3ldctl(these are part of SAP Kernel)
12.Ensure that Enough Space is Available in the Export Directory
13.Use Distribution Monitor if the DB Size is in Tera Bytes
14.Obtain the Migration Key Before in hand.
15.Use Report /sdf/hana_erp_sizing report to Check the target Database.This Report runs for considerable time.