# Update the application


A database migration is hardly ever a database-only migration. You have to look at the application that’s using the database to make sure that it works as expected with the new database. The changes are minimal if you are simply rehosting or replatforming the same database engine, but can be more significant if you decide to move to a new database engine.

If your application relies on an object-relational mapping (ORM) to interact with the database, it won’t require as many changes when you migrate to a new database engine. However, if your application has custom database interactions or dynamically built SQL queries, the changes can be sizable. There might be differences in the query formats that need to be corrected to make sure that the application works as expected.

For example, in Oracle, concatenating a string with `NULL` returns the original string. However, in PostgreSQL, concatenating a string with `NULL` returns `NULL`. Another example is how `NULL` and empty strings are treated. In PostgreSQL, `NULL` and empty strings are two different things, whereas databases like Oracle treat them in the same way. In Oracle, if you insert a row with the column value set to `NULL` or empty string, you can fetch both types of values by using the `where` clause: `where <mycolumn> is NULL`. In PostgreSQL, this `where` clause will return only one row where the column value is actually NULL; it won’t return the row that has an empty string value. For more information about these differences, see the migration playbooks listed on the [AWS Database Migration Service resources](https://aws.amazon.com/dms/resources/) webpage.