Editing Data migration (section)

===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.