Testing a simple conversion: Testing a simple conversion can be as easy as clicking "go" and looking at the target data or as complex as disabling cleanup objects and enabling only specific steps during testing. These automated testing programs are sometimes called "sanity checks". A sanity check may not test everything, but it should tell you if you are in the right ballpark. Methods for checking the output data are determined by the type of data being produced by your package. Some suggested types of checks: Record totals (source count = target count) Sums and averages for accounting information for source and target. Unique records by SSN, Phone Number, or some other unique number A simple check could be a SQL statement that unions' together selects from tables in different databases to show your comparisons in a single sheet. We recommend automating your testing. An automated test is more likely to be run as you develop and will save time in the long run. Automated testing can be added to the same package as the process you are automating. This is useful because the test can be disabled when the package goes into production, and it will be available later if you need to alter or test your Package again. An example of a sanity check in your Package: Select the count of the source records. The count is stored in the variable SourceCount Select the count of the records in the target table. The count is stored in the variable TargetCount Validate on SourceCount = TargetCount. A more complex project could have a Package of its own that produces a report in Excel. We recommend that the sanity check be defined first for larger, more complex projects. Defining the sanity check first has 3 major benefits: You are not developing the sanity check while trying to get the job done. You know when you are done. There are fewer change requests because you thought the project through to the end.