[1][2] Data migration is a key consideration for any system implementation, upgrade, or consolidation, and it is typically performed in such a way as to be as automated as possible, freeing up human resources from tedious tasks.
[2] For applications of moderate to high complexity, these data migration phases may be repeated several times before the new system is considered to be fully validated and deployed.
Planning: The data and applications to be migrated are selected based on business, project, and technical requirements and dependencies.
Migration architecture is decided on and developed, any necessary software licenses are obtained, and change management processes are started.
During verification, there may be a need for a parallel run of both systems to identify areas of disparity and forestall erroneous data loss.
[4] Data is stored on various media in files or databases, and is generated and consumed by software applications, which in turn support business processes.
[6] However, some modern applications are written to be almost entirely agnostic to the database technology,[7] so a change from Sybase, MySQL, IBM Db2 or SQL Server to Oracle should only require a testing cycle to be confident that both functional and non-functional performance has not been adversely affected.
Examples of such migration drivers are mergers and acquisitions, business optimization, and reorganization to attack new markets or respond to competitive threat.
[9] The first two categories of migration are usually routine operational activities that the IT department takes care of without the involvement of the rest of the business.
The last two categories directly affect the operational users of processes and applications, are necessarily complex, and delivering them without significant business downtime can be challenging.