1. SQL Server 2000 to SQL Server 2008 R2 Upgrade
Anna Tarasoff
Technical Solution Professional

2. Agenda Benefits of Upgrading Upgrade Paths and Strategies
Upgrade Considerations
Upgrade Tools
The Upgrade Plan

3. Business Benefits Technical Benefits
Benefits of Upgrading
Business Benefits
Technical Benefits

4. Business Benefits
Next generation data warehousing, reporting, and analysis
Business Intelligence solutions
License and hardware savings
Security, security, security
Data Encryption and Thorough auditing
Performance enhancements
Faster loading of data, faster response
Predictable system response
Scalable and reliable for large enterprises
Application compatibility/Ease of migration
Most applications upgrade seamlessly
Mainstream support
Long term and current support path
Consistent pricing and support
Software Assurance Program
There are enhancements and new capabilities engineered into SQL Server 2008 R2 to enable your applications to run better and reduce the amount of time you need to spend managing them. If you have been running existing applications on SQL Server 2000 or 2005, you will find a set of exciting new capabilities to improve your applications and reduce support needs within a familiar management interface. Many of these new features can provide immediate benefits without the need to make application changes. In addition to the benefits we’ve already discussed, some additional reasons to upgrade include:
Improved system management capabilities
Features like policy based server management and new tools such as Performance Data Collection help you effectively manage the growth of your data.
Performance Enhancements
There have been many performance enhancements made throughout the technology stack, including enhancements within Analysis Services, Reporting Services and Integration Services. For example Unisys and Microsoft set a new ETL performance record by loading one terabyte of data in less than 30 minutes using SQL Server 2008 R2 Integration Services. Read about additional performance records.
Predictable System Response
New Features such as query governor and data compression along with general scalability enhancements provide scalable solutions that are more reliable for very large enterprise systems.
Developer productivity
Tools like Entity Framework and LINQ, and new date/time, FILESTREAM and spatial datatypes provide powerful and easy to use application development enhancements.
Application compatibility and ease of migration
There are upgrade tools available from Microsoft to help manage your upgrade from prior versions. Compatibility has been maintained with the majority of functionality which should enable most applications to upgrade seamlessly. Learn more about all the system changes from the prior version.
Mainstream support
With the latest version of SQL Server you can benefit from a long term and current support path. As of April 2008 SQL Server has moved off Mainstream support to an extended support path.
Consistent pricing and support
Microsoft continues its pricing policies of SQL Server 2005 with some additional improvements. In addition, by participating in Microsoft’s Software Assurance program you are eligible for product upgrades, support and other benefits.

5. Technical Benefits
Data Compression
Resource Governor
Scalability benefits
High availability benefits
Security benefits
Manageability benefits
Data warehousing and data mining benefits
Management and development tools
Integration Services
Improved analysis and reporting
Backup Compression
Automatic Corruption Recovery from Mirror
Standard Performance Reports
Plan Guides for Queries
Change data capture
Star join query optimization
SQL 2008 Upgrade TechnicalReferenceGuide-FeatureComparison-DRAFT3.docx
( rs/sql2008Overview.mspx).
For the Technical Decision Maker, the focus is on the technical benefits of upgrading to SQL Server R2. These can be divided into these broad categories:
Scalability benefits
High availability benefits
Security benefits
Manageability benefits
Data warehousing and data mining benefits
Management and Development tools
Integration Services
Improved analysis and reporting
SQL Server 2008 R2 offers the advantages of a mission critical platform that supports dynamic development and goes beyond relational data, to provide organizations with the pervasive business insight they need.
XML Data Sources
Recordset Destination
Rich Visualization
Self-Service Reporting

6. SQL Server Lifecycle Product released General availability
Mainstream support retired
SQL Server 2000 Standard Edition
11/30/2000
04/08/2008
SQL Server 2000 Enterprise Edition
SQL Server 2005 Enterprise Edition
14/01/2006
12/04/2011
SQL Server 2005 Service Pack 3
15/12/2008
SQL Server 2008 Enterprise Edition
11/07/2008
14/01/2014
SQL Server 2008 R2 Enterprise Edition
20/07/2010
As you can see from the table, mainstream support for all editions of SQL Server 2000 was retired in April 2008, and the product is now on an extended support path.
By upgrading to SQL Server 2008 R2, you can enjoy mainstream support for years to come, through 2014, and extended support will be available through This applies to all editions of SQL Server R2, including Express, Developer, Web, Workgroup and Standard Edition for Small Business.
Source:

7. Upgrade Paths and Strategies

8. Upgrade Paths: SQL Server 2000 SP4 to SQL Server 2008 R2
Benefits
Drawbacks
SQL Server 2000 to
SQL Server 2005 to
SQL Server 2008 R2
Benefits
Drawbacks
There are two basic upgrade paths available when your organization decides to move from SQL Server to SQL Server 2008 R2. Each option has both benefits and drawbacks.
The first option is to upgrade directly from SQL Server 2000 to SQL Server 2008 R2. This may be less time consuming, as it does not require the interim step of upgrading to SQL Server However, existing applications may require significant modification to retain their functionality.
The second option is to upgrade the SQL Server 2000 instance first to SQL Server 2005 and then to SQL Server 2008 R2. This way, application changes can be addressed incrementally. However, this is administratively more intensive and if rollback is necessary, the rollback process is potentially more complex.

9. In-place upgrade 32 bit to 64 bit upgrade one component or database
Upgrade Strategies:
In-place upgrade 32 bit to 64 bit
not supported
In-place upgrade
Replaces legacy SQL Server instance
All components upgraded together
Data file automatically converted
Side-by-side upgrade
Database transferred to separate SQL 2008 instance
Old and new run alongside each other on separate machines or on the same machine
Data is transferred manually
Side by side strategy
Can be used to
upgrade one component or database
SQLServer2008UpgradeTechnicalReferenceGuide-DRAFT3.docx
Whether you decide to upgrade directly to SQL Server 2008 R2 or to do an interim upgrade to SQL Server 2005 and then to SQL Server 2008 R2, there are two different upgrade strategies from which you can choose:
In-place upgrade uses the SQL Server 2008 R2 Setup program to directly upgrade a SQL Server instance to SQL Server 2008 R2. The older SQL Server instance is replaced.
Side-by-side upgrade involves performing operations to move all or data and other database components from SQL Server to a separate SQL Server 2008 R2 instance.
Using an in-place upgrade strategy, the SQL Server 2008 R2 Setup program directly replaces a SQL Server 2000 instance with a new SQL Server 2008 R2 instance on the same x86 or x64 platform; the upgraded instance of SQL Server 2000 is replaced by the new SQL Server 2008 R2 instance. There is no need to copy database-related data from the older instance to SQL Server 2008 R2 because the old data files are automatically converted to the new format. When the process is complete, the old SQL Server 2000 instance is removed from the server, with only retained backups able to restore it to its previous state.
Conversely, in a side-by-side upgrade, database structure and component data are transferred from the SQL Server 2000 instance to a new, distinct SQL Server 2008 R2 instance; the new SQL Server R2 instance runs alongside the legacy SQL Server either on the same server or on a different server. You may also use the side-by-side method to upgrade to SQL Server 2008 R2 on a single server.
The side-by-side upgrade has a couple of notable benefits. With an in-place upgrade, you cannot switch from 32 to 64 bit or vice versa. The side-by-side upgrade also allows you to upgrade just one component or database

10. Upgrade Strategies Advantages
In-place
Side-by-side
Faster and easier
Upgrade single component or database
Mostly automated
Legacy Server stays available
Single name as original
Can go from 32 bit to 64 bit or 64 to 32 bit
Here is a summary of the advantage of each of the upgrade strategies.
Advantages of the in-place upgrade:
An in-place upgrade can be easier and faster, especially for small systems, because data and configuration options do not have to be manually transferred to a new server.
It is mostly an automated process.
The resulting upgraded instance has the same name as the original.
Applications continue to connect to the same instance name.
No additional hardware is required because only the one instance is involved. However additional disk is required by Setup (see "Setup Requirements for an In-Place Upgrade" in the "SQL Server 2008 R2 Setup" section later in this chapter).
Because it is mostly automated, it also takes the least deployment team resources.
Advantage of the side-by-side upgrade:
It gives more granular control over which database objects are upgraded.
The legacy database server can run alongside the new server. You can perform test upgrades and research and resolve compatibility issues without disturbing the production system.
The legacy database server remains available during the upgrade, although it cannot be updated for at least the time it takes to transfer data.
Users can be moved from the legacy system in a staged manner instead of all at once. Even though your system might have passed all validation and acceptance tests, a problem could still occur. But if a problem does occur, you will be able to roll back to the legacy system.
You can go from 32 bit to 64 bit or vice versa.
You can go from non-clustered to clustered.
No additional hardware required
Can go from non-clustered to clustered

11. Upgrade Strategies Comparison at a glance
Process
In-Place Upgrade
Side-by-Side Upgrade
Number of resulting instances
One only
Two
Number of physical servers involved
One
One or more
Data file transfer
Automatic
Manual
SQL Server instance configuration
Supporting tool
SQL Server Setup
Various data transfer methods
This table shows a comparison of some key elements of the upgrade process, depending on whether you do an in-place or a side-by-side upgrade.
Objects requiring manual transfer when you do a side-by-side upgrade include:
Data files
Database objects
SSAS cubes
Configuration settings
Security settings
SQL Server Agent jobs
SSIS packages

12. Upgrade Considerations

13. Operating System Requirements
Windows Server® 2003 SP2 (32-bit or 64-bit)
Standard, Enterprise, and Datacenter Editions
Small Business Server Standard and Premium Editions
Windows Server® 2008 (32-bit or 64-bit)
Standard, Enterprise, and Datacenter
With or without Hyper-V™
Web
SQL Server 2008 R2 will run on the Standard, Enterprise or Datacenter editions of Windows Server (32-bit or 64-bit versions), as well as Small Business Server 2003, Standard or Premium edition. Service Pack 2 needs to be applied.
SQL Server 2008 R2 will also run on any edition of Windows Server 2008 (32-bit or 64-bit version), with or without Hyper-V. However, SQL Server 2008 R2 is not support on Windows Server 2008 Server Core installations.
If you are running SQL Server 2005 on an older operating system, such as Windows 2000 Server, you will need to upgrade the operating system.
SQL Server 2008 R2 is not supported
on Windows Server Server Core installations

14. Hardware Considerations
Memory and processor requirements depend on selected SQL Server 2008 R2 Edition
Standard and Enterprise require 512 MB RAM minimum, 2 GB or more recommended
2 GHz processor is recommended
Minimum hard disk requirements (table)
Feature
Disk Space Minimum Requirement
Database Engine and data files, Replication, and Full-Text Search
280 MB
Analysis Services and data files
90 MB
Reporting Services and Report Manager
120 MB
Integration Services
Client Components
850 MB
SQL Server Books Online and SQL Server Compact Books Online
240 MB
Hardware considerations depend on the selected edition of SQL Server 2008 R2. In general:
Standard and Enterprise editions require a minimum of 512 MB of memory, with 2 GB or more recommended, up to the maximum supported by the operating system.
Processor should be Pentium III compatible or faster; minimum processor speed of 1.0 GHz is required, with 2 GHz or faster recommended.

15. Version and Edition Upgrades
Upgrade from
Supported upgrade path
SQL Server 2000 (32-bit) MSDE SP4
SQL Server 2008 R2 Express
SQL Server 2000 (32-bit) Standard SP4
SQL Server 2008 R2 Standard
SQL Server 2008 R2 Enterprise
SQL Server 2000 (32-bit) Developer SP4
SQL Server 2008 R2 Developer
SQL Server 2000 (32-bit) Enterprise SP4
SQL Server 2000 Enterprise Evaluation (32-bit and IA64)
No upgrade support
SQL Server 2000 (64-bit) IA64 Developer SP4
SQL Server 2008 R2 (64-Bit) IA64 Developer
SQL Server 2000 (64-bit) IA64 Enterprise SP4
SQL Server 2008 R2 (64-Bit) IA64 Enterprise
SQL Server 2000 (32-bit) Personal SP4
This table shows the supported upgrade scenarios based on SQL Server versions and editions. Note the following:
Cross-version instances of SQL Server 2008 R2 are not supported. Version numbers of the Database Engine, Analysis Services, and Reporting Services components must be the same in an instance of SQL Server 2008 R2.
Before upgrading SQL Server, enable Windows Authentication for SQL Server Agent and verify the default configuration: that the SQL Server Agent service account is a member of the SQL Server sysadmin group.
Before upgrading from one edition of SQL Server 2008 R2 to another, verify that the functionality you are currently using is supported in the edition to which you are upgrading.
Cross-platform upgrade is not supported. You cannot upgrade a 32-bit instance of SQL Server to native 64-bit. However, you can upgrade a 32-bit instance of SQL Server to the WOW64: the 32-bit subsystem on a 64-bit server as noted in the table above. You can also back up or detach databases from a 32-bit instance of SQL Server, and then restore or attach them to an instance of SQL Server (64-bit) if the databases are not published in replication. In this case, you must also re- create any logins and other user objects in master, msdb, and model system databases.

16. Issues that will prevent upgrade
Corrective Action
Username of sys in a database – SQL Server 2008 R2 does not permit a username of sys in a database.
Create a new user with a different name, transfer ownership of all database objects to that new user, and drop user sys from the database.
Duplicate login SIDs – SQL Server 2008 R2 does not permit duplicate login SIDs for SQL Server authentication.
Drop and recreate the duplicate SQL Server logins on the legacy system.
Login names matching fixed server role names – SQL Server 2008 R2 does not allow login names to match fixed server role names.
Rename the logins on the legacy system.
Database ID – SQL Server 2008 R2 does not permit a database ID of
Detach and reattach the database and ensure that it gets a new database ID.
Duplicate index names – SQL Server 2008 R2 does not permit duplicate index names on a table.
Rename the indexes so that all indexes are unique within each table.
This table lists some of the issues that will prevent the SQL Server 2008 R2 Setup program from starting the upgrade process for the database engine, and shows the corrective action that should be taken to rectify each problem.
Upgrade Advisor will identify each of these issues.
For more information, see “Planning a SQL Server Installation” on the MSDN site at

17. Upgrade Functionality Considerations
Address Windowing Extensions (AWE)
DBCC DBREINDEX
SET ROWCOUNT for INSERT, UPDATE, and DELETE statements
Deprecated Features
BACKUP LOG WITH TRUNCATE_ONLY
sp_helpgroup
60, 65, and 70 compatibility levels
Discontinued Features
In planning your upgrade to SQL Server 2008 R2, you need to consider how you’ll address deprecated and discontinued features.
Deprecated Features
Features that are deprecated in SQL Server 2008 R2 still operate the same as in the legacy versions, but they will be removed in the next version of SQL Server. Access to these features does not necessarily need to be removed to complete an upgrade, but you should eventually address them because they might cause problems with upgrades after SQL Server 2008 R2. Your upgrade will not be blocked if you use deprecated features. However, it is advised that you decide how or when you want to deal with any of these to give yourself plenty of time to resolve the issues before they are discontinued in some future SQL Server release.
Discontinued Features
It is possible that in any component of SQL Server 2008 R2, some features of earlier SQL Server versions might have been discontinued. These features functioned in earlier versions of SQL Server but have been removed from SQL Server 2008 R2. Although some references to these features might not block an in-place upgrade, you should remove those references anyway. If the reference is not removed, the application might not behave correctly. You can use Upgrade Advisor (which we’ll discuss a little later in this presentation) to detect whether your application is using discontinued features.

18. Upgrade Functionality Considerations
New collations denoted by *_100 version references
CLR Assemblies with conflicting names
Breaking Changes
Query Processor Architecture
Replace function
Tempdb PAGE_VERIFY database option is set to CHECKSUM by default
Behavior Changes
Some features have a different behavior in SQL Server 2008 R2, and others may “break” your applications.
Behavior changes might not visibly affect your database code or applications. However, you have to be aware of them because interpretation might be different. For example, the behavior of the SQL Server Native Client changes from SQL Server 2005 to SQL Server For more information, see Behavior Changes to SQL Server Features in SQL Server 2008 in SQL Server 2008 Books Online.
Breaking changes to SQL Server 2008 are those that might require changes to the applications because the features in question now have a different behavior. If you do not use the feature, there is no effect on you. However, if you do use the feature, your application might be affected. The best tool for discovering this kind of issue is Upgrade Advisor, which analyzes a legacy system and reports on all potential breaking changes and how to address them. For more information about this kind of change, see Breaking Changes to SQL Server Features in SQL Server 2008 in SQL Server 2008 Books Online.
For the most part, SQL Server 2008 R2 is backward compatible with SQL Server 2000 and SQL Server However, you should examine some feature changes during the planning process. The most serious backward-compatibility issues that will affect planning are those that will block an in-place upgrade and prevent an installation of SQL Server 2008 R2. If the SQL Server 2008 R2 Setup program detects these issues in the process of an in-place upgrade, it will abort the install, leaving the legacy instance unchanged. The SQL Server 2008 R2 Upgrade Advisor is the best tool for finding these types of blocking issues ahead of time. These issues do not impact many installations and chances are good that most organizations will encounter few or no issues.
Some changes may require changes to your applications, reporting or replication solutions. These can include:
Database engine changes
Analysis Services changes
Integration Services changes
SSRS changes
Some backward compatibility issues will prevent in-place upgrade. If detected, installation is aborted and the legacy instance is unchanged. We’ll examine some of these in the next slide.

19. Special Upgrade Situations
Upgrading multiple instances
Upgrading very large databases
Upgrading high-availability servers
Upgrading without a database administrator
There are several special situations that require additional consideration. These include:
Upgrading multiple instances of SQL Server database engine
Upgrading very large databases
Upgrading high availability servers
Upgrading Windows Server and SQL Server at the same time
Upgrading without a Database Administrator
You might have multiple instances of SQL Server 2000 or SQL Server 2005 on a standalone or clustered server. Multiple instances can potentially complicate the upgrade process, so you must take them into account before the upgrade. The options are simple: Should all instances be upgraded in one maintenance window, or should you upgrade them individually?
Upgrading them all at once will minimize overall deployment resources because you will need to schedule only a single outage. But that also means that if anything goes wrong for any reason, you might have more to fix and deal with, which could increase downtime. It is a risk versus reward decision.
Many SQL Server databases are in the hundreds of gigabytes or terabytes range. This presents special challenges in any upgrade process because you have to account for constraints in terms of time and hard disk space when dealing with large amounts of data in a short window of maintenance time. Databases in the terabyte range can potentially take days to copy over a network—even the fastest networks. When working with VLDBs, more than any other scenario except perhaps high availability, careful planning is required to ensure a successful upgrade experience.
There are a number of issues related to high availability features such as clustering, database mirroring, log shipping, and replication. You should seek out additional information before upgrading if you use these features.
The key issue in deciding whether to upgrade to SQL Server 2008 R2 without the assistance of a SQL Server DBA is the nature and value of the data you are storing in your current SQL Server instance. If the data is business-critical or irreplaceable, you must address how you would back it up before an upgrade and restore it if you need to roll back the upgrade for any reason. As soon as either of those steps is unclear or uncertain, you should seek the help of a DBA.
64-bit considerations
If you implemented the IA64 version of SQL Server 2000 Enterprise Edition on Windows 2000 Advanced Server Limited Edition, there is no direct upgrade path to SQL Server 2008 R2. You will need to install a fresh installation of Windows Server 2003 or Windows Server 2008, install SQL Server 2008 R2, and then use one of the standard methods such as database attach or a restore to upgrade the databases.
Failover clustering
Because many SQL Server 2000 installations are quite old at this point and the hardware might not be viable, the easiest method for upgrading a SQL Server 2000 failover cluster to SQL Server 2008 R2 is most likely a side-by-side upgrade to a new cluster. Performing an in-place upgrade is possible only if the hardware is viable and you are using Windows Server 2003.
The process for upgrading a SQL Server 2000 or SQL Server 2005 failover clustering instance to SQL Server 2008 R2 is the same. You can perform the upgrade via the command line or through the graphical Setup application. You can find the step-by-step instructions for using the Setup program for an in-place upgrade in the SQL Server 2008 R2 BOL article “How to: Upgrade a SQL Server Failover Cluster Instance (Setup)” ( This section walks through the main steps of an in-place upgrade but does not cover every Setup screen. This section also covers the tasks to perform and considerations to take into account before, during, and after upgrade, especially those not already documented or that might need further context.
Upgrading various services
You also may need to take into account the following issues:
Considerations for upgrading Reporting Services
Considerations for upgrading Analysis Services
Considerations for upgrading Notification Services
Not installed by SQL 2008 Setup
Notification Services compatibility add-in
Considerations for upgrading Integration Services

20. Primary Tools Secondary Tools Additional Tools
Upgrade Tools
Primary Tools
Secondary Tools
Additional Tools

21. Upgrade Tools Overview
Primary Tools
Secondary Tools
SQL Server Upgrade Advisor
SQL Server Upgrade Assistant
Best Practices Analyzer for SQL 2000 and 2005
System Configuration Checker (SCC)
SQL Server Profiler
SQL Server Deprecated Features Object Counter
SQL Server 2008 R2 Upgrade Datasheet.docx
Microsoft and Microsoft partners offer myriad tools to help automate and better ensure the success of the upgrade process to SQL Server 2008 R2. Each tool has its own purpose and timing, so it is best to become familiar with all the tools and then use those most appropriate to each phase of your upgrade.
Primary Tools
The principal tools for planning and executing your SQL Server 2008 R2 upgrade are the SQL Server R2 Upgrade Advisor and DTS upgrade Wizard.
Secondary Tools
There are multiple additional tools that fit specialized needs in the upgrade planning and execution process, including:
SQL Server 2008 R2 Upgrade Assistant
SQL Server Best Practices Analyzer
System Configuration Checker
SQL Server Profiler
SQL Server: Deprecated Features Object Counter
Other tools

22. SQL Server 2008 R2 Upgrade Advisor
Most important tool for upgrade planning
Analyses objects and code within legacy instances
Reports upgrade issues, organized by SQL Server component
Reports can be exported to Excel
Upgrade Advisor can help ease the transition to SQL Server 2008 R2 by detecting potential incompatibility issues in your legacy SQL Server 2000 instance. It analyzes objects and code within legacy instances and produces reports detailing upgrade issues. The resulting reports show detected issues and provide guidance about how to resolve the issues or work around them. The reports are stored on disk, and you can review them by using Upgrade Advisor or export them to Microsoft® Office Excel® for further analysis.
In addition to analyzing data and database objects, SQL Server 2008 R2 Upgrade Advisor can analyze Transact-SQL (T-SQL) scripts and SQL Server Profiler/SQL Trace traces. Upgrade Advisor examines SQL code for syntax that is no longer valid in SQL Server 2008 R2. It generates a report listing the code in question, along with links to where you can find more information to help resolve the questionable code.
SQL SERVER COMPONENTS
Database Engine
Analysis Services
Reporting Services
Integration Services
Data Transformation Services

23. Running Upgrade Advisor
Install SQLUA.msi
from Microsoft web site or
SQL 2008 product disc
Can be installed on:
Windows XP SP2 or later
Windows Vista
Windows Server 2003 SP 1 or later
Windows Server 2008
Upgrade Advisor Home Page Tools
Upgrade Advisor Analysis Wizard
Upgrade Advisor Report Viewer
Upgrade Advisor Help
Whether you choose an in-place upgrade or a side-by-side upgrade, run Upgrade Advisor on your legacy systems. You can run Upgrade Advisor from a local or remote server, and you can execute it from the command window by using a configuration filename as an input parameter.
The Upgrade Advisor requires the following to run:
Windows Server 2008, Windows Server 2003 Service Pack 2 (SP2), Windows Vista® SP1, or Windows® XP SP3
The Microsoft® .NET Framework 2.0 (the same version of the .NET Framework included with SQL Server 2008 R2 and Microsoft® Visual Studio® 2005)
Windows Installer 4.5
SQL Server 2000 Decision Support Objects (DSO) if analyzing SSAS (you can use SQL Server Setup to install DSO)
SQL Server 2000 client components if analyzing DTS (you can use SQL Server 2000 Setup to install the SQL Server 2000 client components)
Pentium III-compatible processor or higher, with a processor speed of at least 500 MHz
15 MB of available hard disk space

24. Upgrade Advisor Analysis Wizard
The upgrade advisor generates a report based on your selections
To prepare for an in-place upgrade of an instance of the relational database engine and its databases, you should run the SQL Server 2008 R2 Upgrade Advisor to analyze installed SQL Server 2000 or SQL Server 2005 relational engine components.
First you select the following:
Components to analyze
Instance name to analyze
Database(s) to analyze
The Upgrade Advisor generates a report based on your selections, which identifies issues that must be resolved before the upgrade and those that you must resolve after Setup completes.

25. Best Practices Analyzer for SQL Server 2000 and 2005
Separate versions for SQL Server 2000 and SQL Server 2005
Download from Microsoft Web site
Run before upgrade to identify bad or questionable practices
Address practices on legacy system if possible for smoother upgrade
Watch for practices that are changed during upgrade process
Before installing SQL Server 2008 R2, you should also run the SQL Server Best Practices Analyzer (BPA) against the SQL Server 2000 instance. If bad or questionable practices exist, you may address them before the upgrade, moving the fixes through test and into production. Using best practices on the legacy SQL Server systems first will help ensure a smoother upgrade.
The Best Practices Analyzer for SQL Server 2000 compiles best practices and recommendations for developing better, more maintainable SQL Server applications and avoiding oversights in managing a SQL Server installation. 

26. SQL Server Profiler Records a running workload
Replays the same activity from a given SQL instance
Compares results to determine:
Whether upgrade behaves properly
Whether upgrade performs well
SQL Server Profiler can record a running workload and then replay that same activity from a given SQL Server instance, making it a valuable tool for preparing an upgrade.
Profiler is useful for simulating an upgrade to determine performance and correct behavior. For example, you can use SQL Server 2008 R2 Profiler to trace a SQL Server 2005 database under load and save the trace. You can then restore the SQL Server 2005 database to two instances on equivalent hardware: a SQL Server 2005 instance and a SQL Server 2008 R2 instance. Run the replay on each (make sure to run the replay at different times if both instances are on the same server). While the replay is running, also run a Profiler trace on each of the two runs, capturing for errors and query durations. By comparing the results, you can determine whether the upgrade behaves correctly (that is, without error) and performs well.
Using Profiler to test upgrade results is much easier if you use the SQL Server 2008 R2 Upgrade Assistant. The Upgrade Assistant helps automate the process and reports for comparing performance and behavior of an upgraded SQL Server instance.
SQL Server Profiler can be used by itself or with the Upgrade Assistant to automate the process and reports

27. System Monitor Performance Counter: Deprecated Features Object
Monitors whether application is sending commands that are scheduled for removal
Can be used to plan modifications to application code for subsequent upgrade
Records total number of times a deprecated feature was encountered since last start
SQL Server 2008 R2 provides a new System Monitor (Perfmon) counter called SQLServer:Deprecated Features to monitor whether your application is submitting commands to the SQL Server 2008 R2 database engine that have been scheduled for removal from SQL Server in future releases. You should remove such deprecated commands from SQL Server 2008 R2 applications after they are detected.
You can use this counter to help plan modifications to your application code so that the process will go more smoothly when you upgrade to the next version of SQL Server after SQL Server 2008 R2. Choose which type of feature to monitor by using the instance selection box for the counter. System Monitor records the total number of times the deprecated feature was encountered since SQL Server 2008 R2 was last started.

28. SQL Server 2008 R2 Upgrade Assistant
Used in test environment
Determines how an existing application will run on SQL Server 2008 R2
Uses Upgrade Advisor with baseline and trace replay
Requirements
Windows Server 2003 R2, Vista or XP SP2 or above
SQL 2000 SP4 or above/SQL 2005 SP2 or above
.NET Framework 2.0 SP1 or above
The SQL Server 2008 R2 Upgrade Assistant is an external tool that lets you determine in a test environment how an application currently running on SQL Server 2000 will run on SQL Server 2008 R2. This tool uses Upgrade Advisor, along with baseline and trace replay in a test environment, to help identify compatibility issues.
Requirements for using Upgrade Assistant are:
Windows Server 2008, Windows Server 2003 R2, Windows Vista, or Windows XP SP2 or later
SQL Server 2000 SP4 or later
Microsoft .NET Framework 2.0 SP1 or later

29. System Configuration Checker (SCC)
Used by Setup for in-place upgrade
Installs .NET Framework and PowerShell™ 1.0
Scans for hardware/software requirements
Checks for conditions that prevent successful installation/upgrade
Reports issues with advice for addressing
Uses rules from four categories
Feature installation
Upgrade and repair
Edition upgrade
Uninstallation
The System Configuration Checker (SCC) performs a scan of the computer in preparation for an installation. SCC looks for conditions that will prevent a successful SQL Server installation or upgrade. These checks occur before Setup starts the SQL Server 2008 R2 Installation Wizard and report any issues that would block an installation, as well as provide advice about how to address the blocking issues.
The Setup SCC uses rules from the following categories:
Feature Installation Rules (
Upgrade and Repair Rules Check (
Edition Upgrade Rules (
Uninstallation Rules (

30. Additional Tools Analysis Services Migration Wizard
Microsoft Assessment and Planning Toolkit
DTS Package Migration Wizard
Analysis Services Migration Wizard
The Analysis Services Migration Wizard can help with a side-by-side upgrade of SSAS.
DTS Package Migration Wizard
Installing SSIS 2008 also installs the DTS Package Migration Wizard, which aids in the migration of DTS packages to SSIS.
Microsoft Assessment and Planning Toolkit 3.2
The Microsoft Assessment and Planning (MAP) Toolkit 3.2 makes it easier for customers and partners to quickly identify what servers, workstations, and network devices are in their IT environment. MAP is a powerful inventory, assessment, and reporting tool that can run in small or large IT environments without requiring the installation of agent software on any computers or devices. The data and analysis provided by this Solution Accelerator can significantly simplify the planning process for migrating to Microsoft SQL Server 2008 R2, as well as Windows Vista, Microsoft Office 2007, Windows Server 2008, Windows Server 2008 Hyper-V, Virtual Server 2005 R2, SQL Server 2008 R2 and Microsoft Application Virtualization 4.5 (formerly SoftGrid), Microsoft Online Services, and Forefront/NAP.
(MAP) performs three key functions: hardware inventory, compatibility analysis, and readiness reporting.
MAP also provides specific and actionable IT proposals and reports to help customers get the most value out of Microsoft products and infrastructure. MAP 3.2 assessment areas now include SQL Server R2 Migration Proposals and Reports.
DTS xChange from Pragmatic Works

31. Plan Creation Flowchart
The Upgrade Plan
Plan Creation
Flowchart

32. Creating an High Level Upgrade Plan
Update skill set
Identify pre-upgrade tasks
Establish performance baselines
Estimate required downtime
Develop upgrade checklists
Create a backup and restore plan
Formulate validation and acceptance criteria
Have a rollback plan
Identify post-deployment tasks
Every upgrade of a production database system that contains valuable data should take place in the context of a good plan. In addition to performing the upgrade-plan tasks we have already covered, you should also adopt some other general best practices when planning for an upgrade.
Updating Skills
Before attempting to upgrade to SQL Server 2008 R2, ensure that those administering or deploying SQL Server 2008 R2 are ready. Just as you would with any other application, never assume that your staff can deploy and then manage the upgraded system without being properly prepared. Before deployment, set up a SQL Server 2008 R2 environment so that everyone who needs to update his or her skill set can become familiar with the new version.
Identify pre-upgrade tasks
This step includes installing Microsoft Windows Installer (MSI) 4.5, .NET Framework 3.5 SP1, and the SQL Server Native Client on the target instances. Because these steps do not affect the application, they can occur before the actual upgrade deployment begins. Note that installing MSI 4.5 requires a reboot of the server.
Establish performance baselines
If performance is a critical feature of the current legacy system, gather data indicating typical performance measurements for important and common queries. Refer to these baselines after the upgrade if reports show that performance has changed. Users might be mistaken, and you might find through the baselines that the new system performs equally well or better. See the "SQL Server 2008 R2 Upgrade Assistant" coverage in the "Upgrade Tools" section earlier in this chapter for a tool that can help establish performance and compatibility baselines.
Estimate required downtime
The deployment of an upgrade will involve some downtime for the targeted database servers. When performing the actual upgrade, allow for enough downtime so that the processes can be completed successfully. Try to give yourself time to roll back in case an unexpected issues arises that cannot be solved in the downtime window; this might mean you reach a go/no-go deadline within your downtime window where you must decide whether to finish the upgrade or roll back.
Develop upgrade checklists
The server environment for targeted database servers might have their own infrastructure complexities. Detail the steps required for taking the systems offline for a period of time and bringing them back online. Also detail the steps to take during the upgrade processes. The upgrade steps, in particular, might be more complex. No matter which method you use, you might need to apply scripts at certain critical points to resolve issues identified by Upgrade Advisor. (For more information about developing checklists, see the "Upgrade Checklists" section later in this chapter.)
Identify backup and restore operations
Although a part of the deployment process, this task is worth calling out separately. One of the first steps in the deployment plan should be to back up the targeted databases. Also verify the backups, and have a strategy for restoring them if needed.
Determine upgrade validation criteria
Clearly state what criteria your organization will use to validate that the upgrade has been successful—in other words, that it produced the result expected. This might consist of scripts run to inspect the SQL Server 2008 R2 instances and verify that issues are resolved, that configuration settings are as expected, and so on. It might include bringing applications online selectively, and processing some transactions to confirm successful operation.
Formulate final acceptance criteria
The upgrade might succeed at the SQL Server 2008 R2 instance level, but some other unaccounted-for variable in the server infrastructure might still prevent applications from running correctly. Whatever the case, identify how the organization will accept the upgrade, and how it will make the "go/no-go" decision. This goes beyond validating the upgrade result: It focuses on whether the applications using the targeted database servers run as expected and required. It might be appropriate to enlist the support of the QA team to develop appropriate acceptance tests.
Formulate a rollback plan
If the upgrade does not succeed or if the acceptance tests do not succeed, be prepared to back out of the process and restore the original conditions. This is much easier to do with a side-by- side strategy than with an in-place upgrade. However, the importance is clear. For example, with an in-place upgrade, a rollback plan might require restoring a disk image (also called a "ghost" image) of the SQL Server 2000 or SQL Server 2005 server, and then restoring the SQL Server 2000 or SQL Server 2005 databases from the deployment backup.
Identify post-deployment steps
Even after the upgrade has been validated and accepted, you might have some remaining tasks to perform, such as updating statistics in the relational database or rebuilding cubes in SSAS. You might also need to reconfigure log shipping, reconfigure database mirroring, re-establish replication, test a failover cluster, or verify that certain SQL Server Agent jobs run correctly.

33. Creating an Upgrade Plan
Update skill set
Attend SQL Server 2008 Administration training
Read the white provided with the web cast
Read TechNet articles provided with the web cast
Identify pre-upgrade tasks
Run Upgrade Advisor Tool
Ensure the server meets hardware and software requirements
Adjust or upgrade hardware if required
Identify software prerequisites
Create test or staging environment for the upgrade testing
Create test plans
Establish performance baselines
Script and schedule SQL Profiler traces to run against production databases over a period of time
Replay the traces against upgraded test environment
Every upgrade of a production database system that contains valuable data should take place in the context of a good plan. In addition to performing the upgrade-plan tasks we have already covered, you should also adopt some other general best practices when planning for an upgrade.
Updating Skills
Before attempting to upgrade to SQL Server 2008 R2, ensure that those administering or deploying SQL Server 2008 R2 are ready. Just as you would with any other application, never assume that your staff can deploy and then manage the upgraded system without being properly prepared. Before deployment, set up a SQL Server 2008 R2 environment so that everyone who needs to update his or her skill set can become familiar with the new version.
Identify pre-upgrade tasks
This step includes installing Microsoft Windows Installer (MSI) 4.5, .NET Framework 3.5 SP1, and the SQL Server Native Client on the target instances. Because these steps do not affect the application, they can occur before the actual upgrade deployment begins. Note that installing MSI 4.5 requires a reboot of the server.
Establish performance baselines
If performance is a critical feature of the current legacy system, gather data indicating typical performance measurements for important and common queries. Refer to these baselines after the upgrade if reports show that performance has changed. Users might be mistaken, and you might find through the baselines that the new system performs equally well or better. See the "SQL Server 2008 R2 Upgrade Assistant" coverage in the "Upgrade Tools" section earlier in this chapter for a tool that can help establish performance and compatibility baselines.
Estimate required downtime
The deployment of an upgrade will involve some downtime for the targeted database servers. When performing the actual upgrade, allow for enough downtime so that the processes can be completed successfully. Try to give yourself time to roll back in case an unexpected issues arises that cannot be solved in the downtime window; this might mean you reach a go/no-go deadline within your downtime window where you must decide whether to finish the upgrade or roll back.
Develop upgrade checklists
The server environment for targeted database servers might have their own infrastructure complexities. Detail the steps required for taking the systems offline for a period of time and bringing them back online. Also detail the steps to take during the upgrade processes. The upgrade steps, in particular, might be more complex. No matter which method you use, you might need to apply scripts at certain critical points to resolve issues identified by Upgrade Advisor. (For more information about developing checklists, see the "Upgrade Checklists" section later in this chapter.)
Identify backup and restore operations
Although a part of the deployment process, this task is worth calling out separately. One of the first steps in the deployment plan should be to back up the targeted databases. Also verify the backups, and have a strategy for restoring them if needed.
Determine upgrade validation criteria
Clearly state what criteria your organization will use to validate that the upgrade has been successful—in other words, that it produced the result expected. This might consist of scripts run to inspect the SQL Server 2008 R2 instances and verify that issues are resolved, that configuration settings are as expected, and so on. It might include bringing applications online selectively, and processing some transactions to confirm successful operation.
Formulate final acceptance criteria
The upgrade might succeed at the SQL Server 2008 R2 instance level, but some other unaccounted-for variable in the server infrastructure might still prevent applications from running correctly. Whatever the case, identify how the organization will accept the upgrade, and how it will make the "go/no-go" decision. This goes beyond validating the upgrade result: It focuses on whether the applications using the targeted database servers run as expected and required. It might be appropriate to enlist the support of the QA team to develop appropriate acceptance tests.
Formulate a rollback plan
If the upgrade does not succeed or if the acceptance tests do not succeed, be prepared to back out of the process and restore the original conditions. This is much easier to do with a side-by- side strategy than with an in-place upgrade. However, the importance is clear. For example, with an in-place upgrade, a rollback plan might require restoring a disk image (also called a "ghost" image) of the SQL Server 2000 or SQL Server 2005 server, and then restoring the SQL Server 2000 or SQL Server 2005 databases from the deployment backup.
Identify post-deployment steps
Even after the upgrade has been validated and accepted, you might have some remaining tasks to perform, such as updating statistics in the relational database or rebuilding cubes in SSAS. You might also need to reconfigure log shipping, reconfigure database mirroring, re-establish replication, test a failover cluster, or verify that certain SQL Server Agent jobs run correctly.

34. Creating an Upgrade Plan
Estimate required downtime
Establish go/no-go deadline
Include upgrade and possible roll back time into the estimation
Develop upgrade checklists
Develop a plan of corrective actions based on Upgrade Advisor output
Script as many steps as possible
Create a backup and restore plan
Formulate validation and acceptance criteria
Document validation criteria
Develop Test Plans
Have a rollback plan
Identify post-deployment tasks
Perform index defragmentation and statistics update
Every upgrade of a production database system that contains valuable data should take place in the context of a good plan. In addition to performing the upgrade-plan tasks we have already covered, you should also adopt some other general best practices when planning for an upgrade.
Updating Skills
Before attempting to upgrade to SQL Server 2008 R2, ensure that those administering or deploying SQL Server 2008 R2 are ready. Just as you would with any other application, never assume that your staff can deploy and then manage the upgraded system without being properly prepared. Before deployment, set up a SQL Server 2008 R2 environment so that everyone who needs to update his or her skill set can become familiar with the new version.
Identify pre-upgrade tasks
This step includes installing Microsoft Windows Installer (MSI) 4.5, .NET Framework 3.5 SP1, and the SQL Server Native Client on the target instances. Because these steps do not affect the application, they can occur before the actual upgrade deployment begins. Note that installing MSI 4.5 requires a reboot of the server.
Establish performance baselines
If performance is a critical feature of the current legacy system, gather data indicating typical performance measurements for important and common queries. Refer to these baselines after the upgrade if reports show that performance has changed. Users might be mistaken, and you might find through the baselines that the new system performs equally well or better. See the "SQL Server 2008 R2 Upgrade Assistant" coverage in the "Upgrade Tools" section earlier in this chapter for a tool that can help establish performance and compatibility baselines.
Estimate required downtime
The deployment of an upgrade will involve some downtime for the targeted database servers. When performing the actual upgrade, allow for enough downtime so that the processes can be completed successfully. Try to give yourself time to roll back in case an unexpected issues arises that cannot be solved in the downtime window; this might mean you reach a go/no-go deadline within your downtime window where you must decide whether to finish the upgrade or roll back.
Develop upgrade checklists
The server environment for targeted database servers might have their own infrastructure complexities. Detail the steps required for taking the systems offline for a period of time and bringing them back online. Also detail the steps to take during the upgrade processes. The upgrade steps, in particular, might be more complex. No matter which method you use, you might need to apply scripts at certain critical points to resolve issues identified by Upgrade Advisor. (For more information about developing checklists, see the "Upgrade Checklists" section later in this chapter.)
Identify backup and restore operations
Although a part of the deployment process, this task is worth calling out separately. One of the first steps in the deployment plan should be to back up the targeted databases. Also verify the backups, and have a strategy for restoring them if needed.
Determine upgrade validation criteria
Clearly state what criteria your organization will use to validate that the upgrade has been successful—in other words, that it produced the result expected. This might consist of scripts run to inspect the SQL Server 2008 R2 instances and verify that issues are resolved, that configuration settings are as expected, and so on. It might include bringing applications online selectively, and processing some transactions to confirm successful operation.
Formulate final acceptance criteria
The upgrade might succeed at the SQL Server 2008 R2 instance level, but some other unaccounted-for variable in the server infrastructure might still prevent applications from running correctly. Whatever the case, identify how the organization will accept the upgrade, and how it will make the "go/no-go" decision. This goes beyond validating the upgrade result: It focuses on whether the applications using the targeted database servers run as expected and required. It might be appropriate to enlist the support of the QA team to develop appropriate acceptance tests.
Formulate a rollback plan
If the upgrade does not succeed or if the acceptance tests do not succeed, be prepared to back out of the process and restore the original conditions. This is much easier to do with a side-by- side strategy than with an in-place upgrade. However, the importance is clear. For example, with an in-place upgrade, a rollback plan might require restoring a disk image (also called a "ghost" image) of the SQL Server 2000 or SQL Server 2005 server, and then restoring the SQL Server 2000 or SQL Server 2005 databases from the deployment backup.
Identify post-deployment steps
Even after the upgrade has been validated and accepted, you might have some remaining tasks to perform, such as updating statistics in the relational database or rebuilding cubes in SSAS. You might also need to reconfigure log shipping, reconfigure database mirroring, re-establish replication, test a failover cluster, or verify that certain SQL Server Agent jobs run correctly.

35. SQL Server 2008 R2 Upgrade Flowchart
This chart illustrates the decision making process from the preparatory phase to completion of the SQL Server 2000 to 2008 upgrade.

36. Identify your upgrade path and strategy
Summary
There are many business and technical benefits in upgrading to SQL Server 2008 R2
Identify your upgrade path and strategy
In summary:
There are many business and technical benefits to upgrading from SQL Server 2000 to SQL Server R2
There are different upgrade paths and strategies to choose from
There are a number of factors to consider before upgrading
There are several available tools to make upgrading easier
Knowing your options and understanding the upgrade process can help you make the decision to upgrade to SQL Server 2008 R2 with confidence.
Create check lists and performance baseline before upgrading and plan for contingency
Use available tools to make upgrading easier

37. Useful Links and Reference Papers
Resources for Upgrading to SQL Server
SQL Server 2005 Upgrade Technical Reference Guide
SQL Server 2008 Upgrade Technical Reference Guide
Database Upgrade to SQL Server 2008 Tools and Approaches

38. Useful Links and Reference Papers
Considerations for Upgrading the Database Engine
Pragmatic Works DTS xChange Upgrade Tool for DTS Packages
Microsoft SQL Server 2008 Upgrade Advisor

39. © 2009 Microsoft Corporation. All rights reserved
© 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.