Three Big Gotchas in moving to SQL 2008

1. Plan before you push the button

Every database migration or upgrade will interrupt normal operations. Migrating data in many instances may be almost push-button simple, but failure to plan in this case is planning to fail. The inevitable issues will crop up in the middle of switching applications, services and users over to a new database. You need a plan that includes an inventory of all the moving parts and a timeline for coordinating and reassembling everything. Without a migration plan, the shiny upgrade button can become a self-destruct button.

Use our expertise and planning templates to help you complete an inventory of everything that is typically overlooked when upgrading or migrating to a new database.

2. Your code just became legacy code

There are new and revised commands in T-SQL; dependencies may be broken due to new and modified system features. In many cases, these changes will require you to review all your current queries, SPs, views, user functions and triggers.

We are experts in performing full life-cycle database migration, including QA on "legacy" applications and code. Our guides and process insure sane migrations!

3. Out with the old, in with the new

There are new functions, methodologies and processes in both SQL 2005 & 2008. These changes affect the management and administration of SQL Server databases significantly from SQL 2000. For example, significant changes were made to the methodology for scheduling and maintaining backups between 2000 and 2005. As a result, porting your existing configuration and processes to the new database may be difficult. It may be easier to reimplement everything building on the new features.

Our checklists and our knowledge can help you decide whether to port or to reimplement administration, integration, and maintenance functions.