The little bit that I know is that the DTS migration tool will work for simple DTS packages, but some of the more complex ones will not convert because there is no exact match for some of the DTS functions in SSIS. Microsoft has a SQL2005 "add-in" you can download that allows 2000 DTS packages to be run & edited in SQL 2005. That's the route we will take initially, then re-write the 2000 DTS packages as 2005 as time & need dictates.

Where I am working, a consultant used the migration wizard for dts->ssis and it has seemed to work well. You cannot use ActiveX scripts, they must be converted to .net Script tasks, but there is additional functionality in ssis and you may not need them any more. There was a glitch though, dts package names cannot have spaces in them or the wizard will hang up before it shows a list of migrate-able packages.

I 've used the Migration Wizard for my DTS packages and it was worked well. But, my new server and database server have different names from the old one. So I have to change the connections from inside every package. How to do that? How to edit the packages since they are already imported in SQL 2005 SSIS? I've tried with BI but there is no deploy option to deploy the package to SSIS repository where my packages are stand on.

In Theory, theory and practice are the same...In practice, they are not.

Sorin Petcu (2/1/2008)I 've used the Migration Wizard for my DTS packages and it was worked well. But, my new server and database server have different names from the old one. So I have to change the connections from inside every package. How to do that? How to edit the packages since they are already imported in SQL 2005 SSIS? I've tried with BI but there is no deploy option to deploy the package to SSIS repository where my packages are stand on.

I've not had any experience migrating DTS to SSIS, however in the migration options is there no option to migrate to file rather than SQL Server?

Granter I am no master in SSIS, but I have used SSIS for several ETL type applications and when it runs OK, its great. Trouble is that failures happen frequently and often for no reason. the worst part about that is that the error messages won't tell what happened, all you get is a red box. I ended up abolishing most packages in favor of SQL scripts executed via SQLCMD.exe.

I like the concepts used but it doen't appear to be worked out properly yet.my 2 cents