Available Migration Resources

Knowing that the changes in architecture and features would essentially break a large number of customers, the Integration Services team developed a set of tools and features that you can use to simplify migration. These tools can be used exclusively or in combination with each other, depending on the approach you take, as discussed in the next section.

Who Is Jim Howey?

Jim is the Program Manager (PM) on the Integration Services team who was largely responsible for, among other things, championing the cause of you, the DTS 2000 user who needs to upgrade packages. In any project of scale and complexity, there are always several priorities that compete for attention and resources. Jim constantly pushed, at times against determined opposition from the author and others, for a better DTS 2000 migration experience. It is largely through his efforts and sturdy determinism that the flexible and substantial options presented here are available. Jim managed the Upgrade Advisor, Migration Wizard, Execute DTS 2000 Package Task, and the SQL Server DTS 2000 Designer Components that make it possible to edit DTS packages in the Execute DTS 2000 Package Task.

So, the next time you successfully upgrade a DTS package or edit one in the Execute DTS 2000 Package Task UI, think of Jim.

Upgrade Advisor

The Upgrade Advisor is a tool that interrogates your servers and builds a report that lists any potential problems you might have when migrating to SQL Server 2005. Running the Upgrade Advisor should be the first thing you do when you're considering an upgrade.

Running the Upgrade Advisor

When you first place the SQL Server setup disk into your machine, there should be a splash screen that appears with several links on it. Figure 3.1 shows the splash screen with the link to install the Upgrade Advisor highlighted.

Figure 3.1. Install the SQL Server Upgrade Advisor from the Setup Splash Screen

Tip

Some users have reported trouble getting the splash screen to show up. You can install the Upgrade Advisor from the disk directly. Under the redist folder, there is an Upgrade Adviser folder with an msi file called SQLUASetup.msi. Right-click on the msi file and select Install to install the Upgrade Advisor.

After you've stepped through the setup and have the Upgrade Advisor installed, you can launch it from the SQL Server 2005 Start menu. Figure 3.2 shows the Upgrade Advisor start page. Some links are provided for finding out more about upgrading. The bottom two links are the most interesting. The first link, Launch Upgrade Advisor Analysis Wizard, lets you perform the actual upgrade analysis. The second link, Launch Upgrade Advisor Report Viewer, lets you view reports generated from previous runs of the Upgrade Advisor.

Figure 3.2. The Upgrade Advisor lets you view reports or run the Upgrade Advisor Analysis Wizard

Click the link to launch the Upgrade Advisor Analysis Wizard. Figure 3.3 shows the first page in the wizard, which tells you the steps you'll take in the wizard.

Figure 3.3. The Upgrade Advisor Analysis Wizard start page details the steps you'll follow

Click the Next button to see the page shown in Figure 3.4. Type in the name of the server and click Detect; the wizard autodetects what SQL Server 2000 components are installed on the server.

Figure 3.4. The wizard autodetects SQL Server 2000 components

For the purposes of this exercise, you are only interested in getting advice about upgrading your DTS packages, so leave only the Data Transformation Services check box checked. Click the Next button, and input your credentials to attach to the server and the instances you want to scan. You can select multiple instances. Click the Next button again to see the dialog box shown in Figure 3.5.

Figure 3.5. The wizard allows you to scan packages on the server or file system

The wizard mentions the Package Migration Wizard, which is covered later. When you select packages on the server, all packages on the server are scanned. There is no way to scan a subset of the packages. Click the Next button and the wizard shows you a summary of the settings. Click the Run button and the wizard starts scanning and analyzing the packages on the server and instances you've selected. Figure 3.6 shows the dialog box shown after the wizard has completed the analysis.

Figure 3.6. The wizard generates a report after performing the analysis

After the wizard has completed the analysis, it writes out the report to the SQL Server 2005 Upgrade Advisor Reports folder under your My Documents folder. You can save these reports to another location and review them later if you want. However, if you leave the report in the same location, the wizard may overwrite it.

Figure 3.7 shows a report the wizard generated for the DTS packages on the test server.

Figure 3.7. The Upgrade Advisor Report Viewer shows the analysis results

You can do a number of things with the reports. You can open existing reports, filter line items by issues or component, and even export them. Pay close attention to the When to Fix column. If it says Before, you'll need to understand that entry well, and possibly take action on it before upgrading. To get more information about each issue, click on the issue in the report. Figure 3.7 shows the expanded description for Meta Data Services packages after clicking on it. Notice that it is possible to lose access to the packages stored in Meta Data Services. Again, it is very important that you take time to scan and analyze your packages before you start your SQL Server installation so that you know about the preinstallation tasks before it is too late. In this case, the Upgrade Advisor is telling the user to move any packages stored in Meta Data Services to SQL Server or save them to the file system before installing SQL Server because they will no longer be accessible after installing SQL Server 2005. Certainly, this is something you'd want to handle before installing.

Caution

Make sure you run the Upgrade Advisor Analysis Wizard before you install SQL Server 2005. It will forecast the problems you might experience when upgrading so you can make informed decisions on how to proceed.

The Execute DTS 2000 Package Task

The Execute DTS 2000 Package Task is a thing of beauty for anyone who needs to use their DTS packages in Integration Services. It provides the entire DTS 2000 package editing environment inside the Business Intelligence Development Studio and a way to execute DTS packages from an Integration Services package. This task is provided to help bridge the gap when migrating from Data Transformation Services to Integration Services. Because the architecture of Integration Services is so different from DTS, few legacy DTS packages will successfully migrate and run in Integration Services. This task provides a "half" migration step so that legacy packages can be run side by side with newer Integration Services packages. Even limited interaction between the two is possible using outer variables such that existing investment in DTS packages is not lost when upgrading to Integration Services. For more information about this task, see Chapter 8, "The Stock Tasks."

Migration Wizard

The Migration Wizard is a way to convert your DTS packages to Integration Services packages. It is a "best efforts" migration, meaning it attempts to migrate the biggest parts of packages, such as tasks and variables. However, in the event that it fails to successfully migrate a package, it migrates those parts of the package that it can and wraps the rest in an Execute DTS 2000 Package Task.

When Package Migration Fails

Many DTS packages will successfully migrate, but most will not. What could cause package migration to fail? The list in Table 3.1 is a good place to start. For example, the DTS Data Transformation Task and the Integration Services Data Flow Task are not compatible and their features don't map to one another. Custom tasks won't migrate because they depend on the DTS object model. The Multiphase Pump and Dynamic Properties Task migration will fail because they have no counterpart tasks in IS and you will probably need to fix up ActiveX Script Tasks, especially if they access the DTS object model.

Because the object models are so different, the package and task properties have changed, and there are so many different package configurations, the odds are against a thoroughly clean migration. Even IS tasks that map well to their DTS counterparts will sometimes fail migration because of some setting that isn't related to the task. For example, the IS packages might be stored on a machine in a different domain without access to the same files or servers. The simple fact that you move the package to a different location can break it. The takeaway here is that there is no free ride. You might get lucky and have great success with migrating a few packages. But, as a general rule, most migrations will be a fairly labor-intensive operation. Fortunately, as discussed in the following section, you have options.

Individual Components and Settings

When it comes to migrating packages, the success or failure of the package migration really boils down to what tasks and connections are in the DTS package. Also, a DTS package is more than a set of tasks. It's a combination of tasks, transforms, logging, and other package settings. A number of DTS-compatible components and settings in Integration Services seem to migrate pretty well with little or no user intervention. In addition, some components and settings don't migrate at all or somewhere in between. Following is a list of DTS components and settings with a very rough expectation of how often each will successfully migrate. The success probability is based on estimates on a number of factors, including the author's own tests, the number of differences between DTS and IS components, the complexity of the component, and wizard support. Notice that none of the success probabilities are estimated at 100%. This is because there are simply too many points of failure when migrating to be sure that any component will succeed all the time.

Caution

The estimates given here for probability of success are the author's. They are strictly based on his experience. You can use them to sanity check the effort it will take to migrate your packages, but please don't rely on these numbers for any substantial commitments. Only by testing in your environment with a representative subset of your packages can you accurately gauge what your migration effort will be.

Migrating Tasks

There seem to be three categories of DTS tasks. The first category is tasks that migrate straight across with few complications and if they don't run successfully the first time, a tweak or two usually fixes any lingering issues. Table 3.2 shows the tasks in this category listed with the IS task to which they migrate.

Table 3.2. Tasks with High Probability of Migration Success

DTS Task	IS Task	Success Probability
File Transfer Protocol	File Transfer Protocol	90%
Execute SQL	Execute SQL	95%
Execute Process	Execute Process	95%
Copy SQL Server Objects	Transfer SQL Server Objects	90%
Send Mail	Send Mail (New SMTP Info)	95%
Bulk Insert	Bulk Insert	70%
Execute Package	Execute DTS 2000 Package	90%
Message Queue	Message Queue	80%
Transfer Error Messages	Transfer Error Messages	95%
Transfer Databases	Transfer Database (one for each database)	85%
Transfer Master Stored Procedures	Transfer Master Stored Procedures	95%
Transfer Jobs	Transfer Jobs	95%
Transfer Logs	Transfer Logs	95%

The second category contains those tasks that might migrate successfully, but often fail because they are either too complex to migrate or they do something that is no longer supported. The ActiveX Script Task often fails to migrate because it contains code that attempts to access the DTS Object Model. The Data Pump Task fails if it is too complex or contains ActiveX Script. The Data Driven Query does not migrate, but the Migration Wizard wraps it in its own DTS package and calls the package from the Execute DTS 2000 Package Task.

Table 3.3. Tasks with Low Probability of Migration Success

DTS Task	IS Task	Success Probability
ActiveX Script	ActiveX Script	40%
Transform Data	Data Flow	40%
Data Driven Query	Execute DTS 2000 Package	40%

The third and final category of tasks is those that simply will not migrate because they are designed to work against a different API or there is no compatible Integration Services task. For example, the Dynamic Properties Task is built upon the premise that it can traverse the package hierarchy and modify other task properties directly. This won't work for two reasons:

• The runtime doesn't allow promiscuous package access any longer.

• Even if it did allow such access, the object model has changed.

Table 3.4. Tasks That Will Not Migrate Successfully

DTS Task	IS Task	Success Probability
Analysis Services	Analysis Services Processing	0%
Dynamic Properties	ActiveX	0%
Data Mining Prediction	Data Mining Query	0%

Migrating Connections

Connections are important in DTS and if the connection doesn't migrate successfully, you've got a broken package just the same as if the task didn't successfully migrate. The good news is that the OLEDB connections, the most common connections in DTS packages, have a very high migration success rate because the settings for the IS OLEDB Connection Manager are identical to its DTS counterpart.

Table 3.5. Various Connection Managers and Their Probability to Successfully Migrate

DTS Connection	IS Connection Manager	Success Probability
OLEDB	OLEDB : OLEDB Provider	99%
Access	OLEDB : Jet 4.0 Provider	95%
Excel	OLEDB : Jet 4.0 Provider	95%
Dbase 5	OLEDB : Jet 4.0 Provider	N/A
HTML File	OLEDB : SQL Native	0%
Paradox	OLEDB: Jet 4.0 Provider	N/A
Text File (Source)	Flat File	0%[*]
Text File (Dest)	Flat File	0%[*]
ODBC	OLEDB: MSDASQL Provider	30%

^[*] The Text File connections migrate to the Flat File Connection Manager, but they will never be complete until you open them in the new package and finish their configuration.

Migrating Settings

The package has a number of settings that impact how the package should run. The Migration Wizard generally ignores these settings. For example, it ignores all the package properties, with the exception of Global Variables. So properties like Package Priority Class, Logging Settings, Fail Package on First Error, Write Completion Status to Event Log, Use Transactions, and so on do not get migrated or in any way affect the properties of the destination IS package. The message here is: Even if your package appears to successfully migrate and you get no errors from the Migration Wizard or the new IS package, this is no guarantee that the package will behave exactly as it did when running under the DTS environment. If you want to retain the values for these properties or the behavior they represent, you need to manually review the package settings and make appropriate settings in the IS package. The Migration Wizard does not do it for you.

Where to Launch the Migration Wizard

You can launch the Migration Wizard from the Business Intelligence Development Studio by right-clicking on the SSIS Packages node in an Integration Services project and selecting the Migrate DTS 2000 Package menu option. You can also launch it from SQL Server Management Studio by right-clicking on the Data Transformation Services node of the Legacy branch in the Management node of SQL Server 2000 servers. The Migration Wizard is a standalone executable, so it can also be launched outside of the designer. On most machines, the Migration Wizard is in the \Program Files\Microsoft SQL Server\90\DTS\Binn\ directory and is named DTSMigrationWizard.exe.

Caution

The Migration Wizard generally fails to migrate a task if the task is missing any settings or if it cannot make a connection. To increase the likelihood of migration success, double check your packages before migrating them to ensure that all the tasks and connections are correctly configured and the servers they reference are online.