Database-first migration changes an application’s data layer before replacing its client or user interface. It preserves a useful front end while moving selected storage responsibilities through a verified access path.
The pattern separates two decisions that are frequently bundled: where information is stored and how people interact with the application. Moving tables can address a storage constraint without discarding forms and workflows that still perform their required role.
The boundary is application behavior
The existing client depends on more than the presence of tables. It depends on types, identifiers, query results, update behavior, errors, and the driver through which it reaches the data. Those dependencies define the compatibility boundary.
A new database can contain the expected records while changing what the client observes. A null, a rounded amount, a generated identifier, or a concurrent update can expose behavior that a simple read trial misses.
The pattern therefore begins with the client’s actual access path. A common interface such as ODBC does not make every database interchangeable. The driver and target engine still implement the operations and return the values the client must interpret.
Access provides a concrete arrangement
An Access application can retain forms, reports, macros, and VBA while tables move to SQL Server. Microsoft’s migration guidance distinguishes the objects handled by SQL Server Migration Assistant from those application objects left in Access.
The resulting system is still an Access application with a changed backend. Calling it a complete application conversion hides the behavior that remains in the client and still needs maintenance.
The same principle applies to other clients only where an appropriate access path exists. A file-based application with assumptions embedded throughout its logic does not gain relational compatibility merely because an importer can read its files.
Inventory readers and writers
A table can have consumers outside the application selected for migration. Reports, spreadsheets, scripts, and other applications can read or update the same data. Moving the table changes those relationships as well.
Write ownership is especially important during coexistence. If the old and new stores accept unrelated updates, their contents can diverge even when the initial transfer was correct. A migration needs a defined authoritative path and a way to account for changes during transition.
Suppose the primary client moves to a server database while a monthly script still updates an old file copy. Daily workflows can appear correct until the monthly process creates a competing state. The migration boundary must include that writer or explicitly end its responsibility.
Validate data and client effects separately
Data comparison checks the agreed transformation. Client acceptance checks whether required operations still complete through the new access path. These are related but distinct results.
Representative cases include edits, conflicting updates, missing values, rounding, generated keys, rejected transactions, and reports. The comparison must preserve meaningful differences rather than normalize them away.
Migration-tool coverage also has limits. AWS DMS row validation requires suitable keys and has documented exclusions. Writes to the target outside its migration process can compromise discrepancy reporting. A tool’s passing result therefore needs its checked population and operating conditions attached.
Cutover changes recovery
Before the new store accepts authoritative writes, returning the client to the old store has a different recovery burden from returning after new transactions exist only on the target. Connection reversal alone cannot transfer those transactions back.
The acceptance plan identifies the source state, synchronization boundary, target write authority, and recovery disposition of new changes. It also covers the client’s deployment configuration so that users do not unknowingly connect to different stores.
What remains fixed is the required application contract. What changes is storage and the access behavior necessary to reach it. Database-first migration is complete for a selected scope when the retained client and every required consumer operate against the accepted data state, with old storage dependencies resolved.