Editing Data migration (section)

==Categories==
Data is stored on various media in [[Computer file|files]] or [[databases]], and is generated and consumed by [[software applications]], which in turn support [[business processes]]. The need to transfer and convert data can be driven by multiple business requirements, and the approach taken to the migration depends on those requirements. Four major migration categories are proposed on this basis.

===Storage migration===
A business may choose to rationalize the physical media to take advantage of more efficient storage technologies.<ref name="DufrasneDS8870_17" /> This will result in having to move physical blocks of data from one tape or disk to another, often using [[Storage virtualization|virtualization]] techniques. The data format and content itself will not usually be changed in the process and can normally be achieved with minimal or no impact to the layers above.<ref name="SeiwertData12">{{cite book |chapter-url=https://books.google.com/books?id=zr26AgAAQBAJ&pg=PA7 |chapter=Chapter 2: Migration techniques and processes |title=Data Migration to IBM Disk Storage Systems |author=Seiwert, C. |author2=Klee, P. |author3=Marinez, L.|display-authors=et al |publisher=IBM Redbooks |pages=7–30 |year=2012 |isbn=9780738436289}}</ref>

===Database migration===
{{main|Schema migration}}
Similarly, it may be necessary to move from one [[database]] vendor to another, or to upgrade the database software being used. The latter case is less likely to require a physical data migration, but this can happen with major upgrades. In these cases a physical transformation process may be required since the underlying data format can change significantly. This may or may not affect behavior in the applications layer, depending largely on whether the data manipulation language or protocol has changed.<ref name="FowlerRefactoring12">{{cite book |url=https://books.google.com/books?id=HmrDHwgkbPsC&pg=PA63 |title=Refactoring: Improving the Design of Existing Code |author=Fowler, M. |author2=Beck, K. |author3=Brant, J.|display-authors=et al |publisher=Addison-Wesley |pages=63–4 |year=2012 |isbn=9780133065268}}</ref> However, some modern applications are written to be almost entirely agnostic to the database technology,<ref name="FroncDatabase15">{{cite web |url=https://dba-presents.com/index.php/other/my-thoughts/34-database-agnostic-applications |title=Database-agnostic applications |author=Fronc, A. |work=DBA Presents |date=1 March 2015 |access-date=20 July 2018}}</ref> so a change from [[Sybase]], [[MySQL]], [[IBM Db2]] or [[Microsoft SQL Server|SQL Server]] to [[Oracle Database|Oracle]] should only require a testing cycle to be confident that both functional and non-functional performance has not been adversely affected.

===Application migration===
Changing application vendor—for instance a new [[Customer relationship management|CRM]] or [[Enterprise resource planning|ERP]] platform—will inevitably involve substantial transformation as almost every application or suite operates on its own specific data model and also interacts with other applications and systems within the [[enterprise application integration]] environment.<ref name="PlivnaData">{{cite web |url=http://www.gplivna.eu/papers/legacy_app_migration.htm |title=Data migration from old to new application: An experience |author=Plivna, G. |work=gplivna.eu |date=1 July 2006 |access-date=20 July 2018}}</ref> Furthermore, to allow the application to be sold to the widest possible market, commercial off-the-shelf packages are generally configured for each customer using [[metadata]]. [[Application programming interfaces]] (APIs) may be supplied by vendors to protect the [[data integrity|integrity of the data]] they must handle.

===Business process migration===
[[Business processes]] operate through a combination of human and application systems actions, often orchestrated by [[business process management]] tools. When these change they can require the movement of data from one store, database or application to another to reflect the changes to the organization and information about customers, products and operations. Examples of such migration drivers are mergers and acquisitions, business optimization, and reorganization to attack new markets or respond to competitive threat.<ref name="AllenMulti15">{{cite book |url=https://books.google.com/books?id=y-ScBAAAQBAJ&pg=PA61 |title=Multi-Domain Master Data Management: Advanced MDM and Data Governance in Practice |author1=Allen, M. |author2=Cervo, D.  |publisher=Morgan Kaufmann |pages=61–2 |year=2015 |isbn=9780128011478}}</ref>

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. A highly adaptive approach, concurrent synchronization, a business-oriented audit capability, and clear visibility of the migration for stakeholders—through a project management office or data governance team—are likely to be key requirements in such migrations.<ref name="AllenMulti15" />